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The invention concerns a terminal com- 
prising a terminal module (1) and a personal se- 
curity device (31). The terminal (1) is adapted 
for receiving requests from an application (Fap) 
implanted on an electronic unit in the form of 
high level requests independent of the module (1) 
and of said personal security device (31). One at 
least of the terminal module (1) and the personal 
security device (31) comprises a reprogrammable 
storage memory and means for executing a filter 
software (F) translating the high level requests 
into at least one of (i) at least one data exchange 
sequence between the terminal module (1) and 
the user or (ii) at least an elementary command 
or sequence of commands executable by the per- 
sonal security device, and means for protecting 
said filter software (F, 62) to prevent any modifi- 
cation of said software by a non-authorised per- 
son. The filter software comprises means for identifying and/or authenticating the origin of requests transmitted by said application (Fap) 
implanted in said unit. ■ 
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(57) AbrSge 

Ce terminal comprend un module terminal (1) et un dispositif personnel de securit6 (31). Le terminal (1) est adapt6 pour recevoir des 
requites d'une application (Fap) implantee sur une unite* 61ectronique sous la forme de requetes de haut niveau inddpendants du module (1) 
et dudit dispositif personnel de sdcuriri (31). L'un au moins du module terminal (1) et du dispositif personnel de security (31) comprend 
une mdmoire reprogrammable de stockage et des moyens d'exdcution d'un logiciel filtre (F) traduisant les requetes de haut niveau en au 
moins Tune de (i) au moins une sequence d'echange de donnees entre le module terminal (1) et Tutilisateur ou (ii) au moins une commande 
el6mentaire ou une s6quence de commandes elementaires executables par le dispositif personnel de security ainsi que des moyens de 
protection dudit logiciel filtre (F, 62), pour empecher toute modification dudit logiciel par une personne non autorisee. Le logiciel filtre 
comprend des moyens d' identification et/ou d'authentification de roriginc des requetes emises par ladite application (Fap) implantee dans 
ladite unit6. ; 
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Terminal et svstSme pour la mise en oeuvre de transac tions electroninues securkPP<; 

La presente invention concerne un terminal et un systeme pour la mise en oeuvre de 
transactions 6lectroniques securisees. 

Les reseaux publics de transmission de donnees numeriques, tels que le reseau 
Internet, connaissent un developpement considerable. Cependant, I'un des freins qui 
5 limitent actuellement la mise en oeuvre de transactions 6lectroniques securisees sur ce type 
de reseau reside dans I'insuffisance des m£canismes de security associes £ de telles 
transactions, insuffisance qui se traduit par un manque de confiance des utilisateurs et 
op§rateurs de reseaux. 

Au sens de la presente demande : 
10 - une transaction electronique designe un ^change d'informations, via un r£s£au public 

de transmission de donnees numeriques ou de telecommunications, soit entre deux ou 
plusieurs utilisateurs, soit entre un utilisateur et un fournisseur de services, 

- une fonction est un traitement effectue dans I'objectif de rendre un service k un utilisateur, 

- une application designe un ensemble coherent de services et de fonctions, 

1 5 - Pexpression logiciel duplication designe le ou les logiciels necessaires pour mettre en 

ceuvre les fonctions relatives k une application donn£e, 

- une transaction securis^e est une transaction pour laquelle certaines mesures de 
s£curite sont prises, k savoir Pauthentification des entitSs participant k la transaction, 
I'ihtegrite, la confidentialite, I'authenticite, et 6ventuellement la non repudiation des 

20 ^changes et operations effectuees dans le cadre de la transaction. 

De nombreuses applications necessitent que les transactions electroniques mises en 
ceuvre soient securis£es. II s'agit par exemple du controle d'acc^s & des ressources 
informatiques ou similaires, de la banque k domicile (consultation, mouvements de comptes 
bancaires, etc... par I' intermediate du reseau telephonique ou d'lnternet), du commerce 
25 £lectronique (achat de biens ou services par I'intermgdiaire d'un reseau public), du courrier 
electronique, du porte-monnaie £Iectronique, etc... 

Ces applications, ainsi que d'autres, necessitant des transactions securisees sont bien 
connues des spScialistes de la technique et ne sont pas d£crites ici en details. 

Suivant leur nature, la s6curisation de ces applications necessite la mise en oeuvre d'un 
30 ou plusieurs services de security tels que : 

- I'authentification, qui permet de garantir I'identite d'une entite (une personne ou un systeme) ; 

- le contrdle d'acc£s, qui confere une protection contre ('utilisation ou la manipulation 
non autoris^e de ressources ; 

- la confidentialite, qui interdtt la divulgation de donnees k des entites non autorisees ; 
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- Pintegrite de donnees, qui assure que des donn<§es n'ont pas 6te modifiees, supprimees 
ou substitutes sans autorisation ; 

- la non repudiation, qui assure qu'un participant k un echange de donnees ne pourra 
pas ulterieurement nier Pexistence de cet ^change. 

5 La combinaison de deux techniques existantes penmet d'envisager la mise en oeuvre 

de ces services de security offrant ainsi un niveau de securite suffisant pour effectuer des 
transactions electroniques. 
Ils'agitde: 

- la cryptographie k de publique et c!6 privSe, car elle permet de.garantir la non 
10 repudiation et facilite la gestion des ci£s ; 

- la carte k circuit integr£ (ou "smart card") car elle est peu couteuse, facile k utiliser et 
sure grace k des microprocesseurs specifiques dotes de protections mat£rielles et logicielles 
permettant d'interdire Pacc6s en lecture et en Venture a leurs memoires. 

Les cartes k circuit int£gre offrent les services suivants : 
1 5 * Pauthentification du porteur ou utilisateur de la carte : cette operation permet d'authentifier le 

porteur k Paide d'un code confidentiel et k la carte d'accepter par la suite la mise en ceuvre 
d'operations telles que Pex<§cution d'algorithmes, la lecture de cits secr&es, la lecture et/ou Ptaiture 
de donnees dans la carte, qui peuvent en outre Stre soumises k d'autres conditions de security ; 

* la protection des donnees et fonctions stock£es sur la carte k circuit integre. L'acc£s k la 
20 carte peut §tre soumis k une authentification pr£alable de Pentit£ electronique demandant k y 

acc£der. Cette authentification exteme se fait gen£ralement en mode challenge/reponse. Dans ce 
cas, Pentite dispose d'un param&re secret, ci-apr£s appele egalement secret, qui lui permet de 
caiculer, en fonction d'un challenge £mis par la carte, une r6ponse qui prouvera k la carte qu'elle 
est en possession du secret ; 
25 * execution d'algorithmes cryptographiques utilisant un param&re secret memorise dans la 

carte (chiffrement, authentification de message, signature) ; 

* authentification interne. Ce service permet k une application d'authentifier la carte. Ce 
service est Pinverse d'une authentification exteme. La carte g£n£re une reponse en fonction d'un 
challenge regu et d'un secret stocke dans la carte. 

30 Les services offerts par la carte k circuit int£gr£ sont mis en ceuvre sur reception de 

commandes dites el£mentaires, ('execution de la commande £lementaire provoquant Penvoi 
de reponses elementaires. Ces commandes elementaires concernent, par exemple, des 
. calculs cryptographiques, la lecture ou I'ecriture de donnees secretes ou non, des 
interventions de Putilisateur (saisie de son code confidentiel personnel PIN, validation d'une 
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transaction apr£s signature), les retours d'information vers i'utilisateur (affichage des 
messages k signer, par exemple). 

Certaines cartes offrent la possibility de verifier I'integrity, I'origine, voire la 
confidentiality des commandes envoyees k la carte. Ces services reposent sur des techniques 
5 d'authentification et de chiffrement des commandes. 

[.'utilisation qui est faite actuellement des cartes k circuit integrS (ou cartes k micro- 
circuit) offre un degry tr£s yieve de s^curite car les transactions sont essentiellement mises en 
oeuvre sur des reseaux priv^s et des terminaux (distributeurs automatiques de billets, 
terminaux points de vente par exemple) qui sont sous le contrdle d'une entite assurant la 
10 securite de I'ensemble du systeme. 

Dans de telles applications, les utilisateurs ou d'eventuels fraudeurs n'ont pas accks au logiciel 
d'application, ni aux mycanismes de security matyriels et logiciels dont sont dotys les terminaux. 

Par contre, la mise en ceuvre de transactions securisyes avec des cartes k circuit integre sur 
un ryseau public suppose que les utilisateurs aient k leur disposition un module terminal lecteur 
15 de carte, ytant donny que ces cartes ci micro-circuit ne sont pas dotees d'une source d'ynergie 
electrique propre et que leur mise en oeuvre requiert un lecteur susceptible de les alimenter et 
d'ytablir une communication avec Putilisateur et/ou des moyens yiectroniques extyrieurs. 

A I'heure actuelle, pour ryaliser une transaction sur un ryseau public, I'utilisateur 
dispose d'un terminal, qui peut etre un produit dydiy, un ordinateur personnel, ou un 
20 ordinateur personnel couply k une carte k circuit integry par un lecteur de carte. 

Dans tous les cas, le systeme de transactions k la disposition de I'utilisateur est en 
gynyral constituy de : 

• un foumisseur de services applicatifs pouvant §tre, par exemple, un navigateur Internet, 
un logiciel de messagerie, un logiciel de banque k domicile ("Home banking"), 
25 • un foumisseur de services de security de haut niveau permettant I'execution des 
mycanismes cryptographiques de bas niveau requis par ('application. 

Le foumisseur de services applicatifs emet des requetes de services de sycurity de haut 
niveau pour assurer la sycurity des transactions mises en ceuvre. 

Dans le cas ou ('application est implantye sur I'ordinateur personnel de I'utilisateur, les 
30 services cryptographiques auxquels il est fait ryfyrence sont, par exemple, ceux dyfinis par la 
Society RSA Laboratories dans son standard "PKCS 11 : Cryptographic Token Interface 
Standard", ou encore les services cryptographiques offerts par le systyme d'exploitation 
Windows NT de Microsoft, en particulier ceux proposys par ('Interface des programmes 
d'application (API) "Crypto API". 
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Lorsque I'utilisateur ne dispose pas de lecteur de carte k circuit integre, les services 
cryptographiques sont realises de manure logicielle uniquement. 

Lorsque I'utilisateur veut amEliorer la securite, il utilise un lecteur de carte k circuit 
integre de type transparent connecte a son ordinateur, Un lecteur de carte de type 
5 transparent est en fait un boitier d'interface entre I'ordinateur et la carte k circuit integre qui 
permet de transmettre des commandes elementaires de I'ordinateur, provenant du 
fournisseur de services cryptographiques, vers la carte, et les rEponses Elementaires de la 
carte vers I'ordinateur. Un utilisateur peut, k Paide de ce terminal, (constitue de son module 
terminal - ordinateur + lecteur - couple k sa carte) effectuer des transactions electroniques 
1 0 (commerce Electronique par exemple). 

Bien entendu, I'acc&s des utilisateurs k un tel terminal engendre des risques potentiels 
du point de vue de la sEcurite. 

Les risques encourus seront d'autant plus grands que les applications seront 
dEcentralisees. Et vice versa, les applications pourront fitre d'autant plus decentralisees, que 
15 les risques c6t6 terminaux seront maitrisEs. Par exemple, on peut envisager des applications 
de type porte-monnaie, dans lesquelles les transactions (d6bit de la carte acheteur/credit de 
la carte commergant) se feront de carte k carte, sans necessiter une consolidation des 
transactions au niveau d'un serveur central. 

II rEsulte de ce qui precede, qu'un terminal peut potentiellement contenir un 
20 ensemble- deformations, voire des logiciels, sur la confidentiality et I'integrite desquels 
repose la sEcuritE de I'application. Comme exemple, on peut citer des clEs secretes utilisees 
pour I'authentification du module terminal vis-£-vis de la carte, ou pour le chiffrement de 
donnEes entre un serveur et le module terminal lecteur de carte. Or, un fraudeur peut 
profiter du fait d'avoir k sa disposition un terminal pour analyser son fonctionnement et 
25 acceder aux informations et logiciels confidentiels. 

II faut Egalement noter que les applications auxquelles il est fait reference ici, telles 
que le commerce ou le courrier Electronique, sont la plupart du temps mises en oeuvre k 
travers le reseau Internet. II est bien connu des experts qu'un ordinateur personnel ou PC 
connecte au reseau Internet est trEs vulnerable aux logiciels de type virus, qui peuvent etre 
30 installs et executes sur le PC de I'utilisateur sans m6me qu'il le sache et sans qu'il ait laissE 
un acc£s physique k son ordinateur k qui que ce soit. Le c6t6 totalement invisible de ce type 
de menace reprEsente le r£el danger qui limite k I'heure actuelle le dEploiement des 
applications transactionnelles utilisant Internet. Les m&mes commentaires peuvent 
s'appliquer aux applications de commerce Electroniques envisages k partir des reseaux 
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cables de television en utilisant des decodeurs ou "set-top box" raccordys au poste de 
television et comportant un ou deux lecteurs de cartes k puce. 
Les risques au niveau du systeme sont alors les suivants : 

• Attaque sur i'intygrity du foumisseur de services cryptographiques et du fournisseur de 
5 services applicatifs visant k modifier le comportement du module terminal : a titre 

d'exemple, le module terminal est modify de manure k capturer les informations liees k la 
carte, stocker les informations obtenues pour ensuite les communiquer k un faux serveur. 
Cette attaque peut ytre r^alisee k Pinsu de I'utilisateur legitime (substitution du module 
terminal de I'utilisateur ou pr£t d'un module terminal mod if iy). Cette attaque peut ensuite se 
1 0 generaliser sous la forme de la diffusion de modules terminaux contrefaits ; 

• Attaque sur la confidentiality du foumisseur de services cryptographiques, visant k se 
procurer les cl6s cryptographiques qu'il manipule, lesquelles cl^s sont par exemple stockees 
sur le disque dur d'un ordinateur. 

• Attaque vis-a-vis d'autres cartes, bas^e sur une capacity a pouvoir s'authentifier vis-a-vis de ces 
1 5 cartes, grace aux secrets decouverts par une attaque sur la confidentiality du foumisseur de services. 

• Attaque sur I'integrite et la confidentiality des communications entre les differentes 
entites (foumisseurs de services applicatifs, foumisseurs de services cryptographiques, 
lecteur de carte k circuit intygry, carte k circuit intygry, serveur) permettant de rompre la 
chaine de confiance ytablie entre ces elements . Par exemple: 

20 1 - dechiffrement des communications entre serveur et terminaux ; 

2 - insertion d'un logiciel tiers entre le foumisseur de services applicatifs et le foumisseur de 
services cryptographiques visant k rompre la chaine de confiance entre ces deux logiciels ou bien 
substitution du logiciel applicatif par un logiciel tiers visant k faire executer au foumisseur de 
services de sycurity des requites de security dans un but different de celui de ('application 

25 connue de I'utilisateur. 

• Attaque sur les serveurs (dans le cas d'une application en mode connecte) : connexion 
d'un terminal contrefait k un serveur, ymulation d'un couple module terminal-carte k circuit 
intygry pour obtenir des avantages. 

Ainsi, une attaque sur la chaine de confiance entre le fournisseur de services 
30 cryptographiques et le fournisseur de services applicatifs, dans le cadre d'une application 
requyrant la signature d'une transaction yiectronique k I'aide d'une carte a circuit integre, est 
illustrye ci-aprys. Le dyroulement de la transaction est le suivant : 

- Etape 1 : vyrification du code confidentiel personnel (PIN) de I'utilisateur, que celui- 
ci introduit par un clavier associy k son module terminal, le code introduit etant transmis k la 
35 carte pour vyrification par cette derniyre. 
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- Etape 2 : authentification du module terminal. Ce dernier envoie une commande 
"demande challenge". (Un challenge est un nombre aleatoire ou pseudoaleatoire). La carte 
k circuit integrt gtntre le challenge et le transmet au module terminal. Le module terminal, 
envoie k la carte une commande "authentification externe" accompagnee d'une rtponse 

5 constitute du challenge chiffrt par une cle d&enue par le module terminal. La carte k circuit 
inttgre verifie alors la reponse re?ue. 

- Etape 3 : si les Stapes 1 et 2 se sont deroulees de manure satisfaisante, la carte k 
circuit integre est prgte k recevoir et executer la commande signature, c'est-^-dire une 
commande de chiffrement, au moyen d'une cle privee stockee dans la carte, du resultat 

10 d'une operation de hachage rtalisee sur la transaction saisie par I'utilisateur. Aprts ce 
chiffrement, la carte tmet, k destination du module terminal, la signature constitute du. 
resultat de ('operation de hachage ("hash") ainsi chiffrt. 

Si I'inttgrite du logiciel duplication (foumisseur de services applicatifs et son 
fournisseur de services cryptographiques) n'est pas assume, un fraudeur n'a pas besoin de 

15 connaitre les cits et codes secrets pour pirater le systtme de transaction ': il lui suffit 
d'implanter dans le module terminal, par exemple dans I'ordinateur personnel auquel est 
raccorde un lecteur de carte k circuit inttgrt, un logiciel de type virus qui, k Petape 3, 
detourne les donntes authentiques k signer et envoie k la carte des donntes falsifiees. Etant 
donne que les Stapes 1 et 2 se sont deroulees de manure satisfaisante, la carte signera alors 

20 les donnees falsifies sur la base du PIN que I'utilisateur a lui-meme introduit et celui-ci 
croira que la carte va signer ses propres donnees. 

L'exemple prtcedant montre la necessity de proteger non seulement les informations 
confidentielles mises en oeuvre dans le cadre d'une transaction, mais aussi I'inttgrite de la 
transaction, c'est-^-dire I'inttgrite du comportement de chaque entite intervenant dans la 

25 transaction, ainsi que I'integritt du comportement d'ensemble du logiciel en veillant k la non 
rupture de la chaTne de confiance ttablie entre les differentes entitts. 

Les risques d'attaque mentionnts ci-dessus sont k I'heure actuelle en partie couverts 
par des terminaux - lecteurs de carte k circuit inttgre integrant des modules de securite 
(SAM, analogue k une carte k circuit inttgre) qui sont utilises notamment dans le cadre des 

30 applications porte-monnaie. Le lecteur est alors personnalist par un SAM, et attribue k un 
commer^ant, les cartes lues ttant celles des clients. Ce SAM contient des informations 
secretes et est susceptible d'executer des algorithmes utilisant ces informations secretes. 
Mais, il ne contient pas de moyens permettant notamment de piloter les communications 
avec I'utilisateur, avec la carte k circuit inttgrt et/ou avec des moyens tlectroniques 

35 exttrieurs, et done la stcurisation de transaction n'est pas assume. 
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II est egalement connu par le document WO 95/04328 un module terminal 
comprenant des moyens d'interface avec I'utilisateur et des moyens d'interface avec des 
moyens electroniques exterieurs (ci-apr£s appel£s moyens d'interface externe), comportant 
une interface avec une carte k micro-circuit. Le microprocesseur du module terminal 
5 comprend des moyens de stockage de donnees (ROM, EEPROM, RAM). Les donn^es 
stockSes en memoire permanente (ROM) comprennent entre autres un syst&me 
d'exploitation, des gestionnaires de composants externes pilotant les interfaces et 
peripheriques, et un interpr&eur capable d'interpr&er des modules programmes ecrits dans 
un langage sp<§cifique. Les modules programmes sont stockSs dans la memoire semi- 

10 permanente EEPROM et peuvent £tre charges en memoire temporaire RAM pour gtre 
executes par le microprocesseur lors de .('activation d'une interface appropriee par 
I'utilisateur. Les modules programmes, correspondant aux applications du module terminal, 
sont t6lecharg6s dans la memoire EEPROM du microprocesseur ou dans une carte a micro- 
circuit k partir d'un serveur exteme. 

1 5 Le module terminal du document WO95/04328 peut fonctionner : 

- en mode module terminal autonome, le microprocesseur du module terminal executant un 
module programme stocks dans une memoire interne, sans faine appel k une carte a circuit integre ; 

- en mode terminal autonome, dans lequel un module programme stocke dans une carte 
est execute ; 

20 - en mode terminal Stendu ou connecte, dans lequel le microprocesseur du module terminal ou 
celui de la carte execute un module programme et une communication est etablie via le 
telephone, un modem ou une liaison directe avec un foumisseur de services ou un serveur ; 

- en mode lecteur de carte a memoire transparent, dans lequel des instructions refues par 
une liaison s6rie sont transmises directement k la carte et vice et versa. 

25 Le terminal ddcrit au document WO 95/04328 ne traite pas des probl£mes de securite 

vises par 1'invention dans la mesure ou il ne dScrit pas comment sScuriser une transaction en 
garantissant I'integrite du comportement d'ensemble du logiciel executant la transaction. II ne 
d&rrit notamment pas de moyens permettant l'ex6cution de requ&es de haut niveau Smises par 
Tapplication, ni comment garantir I'origine, ('integrity et la confidentiality de ces moyens. 

30 La pr£sente invention vise k fournir un terminal pour la mise en oeuvre de transactions 

Electroniques securisEes, du type comprenant un dispositif personnel de securite tel qu'une 
carte k circuit int6gr6 ou autre dispositif remplissant les memes fonctions, et un module 
terminal dote de moyens d'interface avec le dispositif personnel de securite, tels qu'un 
lecteur de carte k circuit intEgrE, et offrant de par son architecture logicielle et/ou rnaterielle 

35 et les mScanismes de s6curit6 qu'il comporte, un niveau de securite ameliore, compatible 
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avec le fait que le terminal peut §tre plac£ sous te contrdle des utilisateurs, (par opposition k 
des terminaux contrflles par des op£rateurs). 

Un deuxteme objectif de I'invention est d'assurer ce mSme niveau de securite tout en 
permettant ('integration, en cours d'utilisation, de fonctions ou applications nouvelles, ou 
5 I Evolution des fonctions ou applications existantes sans avoir recours k une multitude de 
modules terminaux differents ou au changement des modules terminaux lors des Evolutions. 

A cet effet, I'invention a pour objet un terminal pour la mise en oeuvre, par un 
utilisateur, de transactions electroniques s<§curis6es en liaison avec au moins une application 
implantee sur une unite electronique, ledit terminal comprenant : 
10 - un module terminal comportant au moins : 

• des premiers moyens d'interface avec ladite application pour en recevoir des 
requStes relatives auxdites transactions, 

• des deuxi&mes moyens d'interface avec ledit utilisateur, 

• des troistemes moyens d'interface avec un dispositif personnel de securite, 

1 5 • des premiers moyens de traitement de donnees comprenant au moins des premiers 

moyens logiciels de pilotage desdits moyens dMnterface, et 
- un dispositif personnel de securite comportant au moins des deuxiemes moyens de 
traitement de donnees securis^es comprenant au moins des deuxiemes moyens logiciels 
d'exEcution de commandes elementaires et des moyens d'ex&rution de calculs 
20 cryptographiques, caracterisS en ce que : 

* ledit terminal est adapts pour recevoir lesdites requetes de ladite application 
implantee sur ladite unite electronique sous la forme de requites de haut niveau 
independantes dudit dispositif personnel de security 

* Pun au moins dudit module terminal et dudit dispositif personnel de securite comprend : 
25 • au moins une memoire reprogrammable de stockage d'au moins un logiciel filtre, 

traduisant lesdites requites de haut niveau en en au moins Tune de : 

(i) au moins une commande 6l6mentaire ou une sequence de commandes 

Stementaires executables par lesdits deuxtemes logiciels desdits deuxtemes 

moyens de traitement de donnees, ou 
30 (ii) au moins une sequence d'<§change de donnees entre ledit module terminal et 

ledit utilisateur via lesdits seconds moyens d'interface, ledit echange de donnees 

etant execute par lesdits premiers moyens logiciels desdits premiers moyens de 

traitement de donnees, 
• des moyens de protection dudit logiciel filtre pour empScher toute lecture 
35 et/ou modification dudit logiciel par une personne non autorisee, et 
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* Pun au moins desdits premiers et deuxi£mes moyens de traitement .de donnees 
comprend un dispositif de traitement de donnees pour ('execution dudit logiciel filtre. 
(.'invention definie ci-dessus permet d'atteindre les objectifs de security requis par la 
mise en oeuvre de transactions electroniques grace au fait qu'elle d£crit un filtre ou pare-feu 
5 T firewall") entre le monde exterieur, c'est-^-dire les applications elles-memes, et les 
moyens de s£curit£ et p6riph6riques qu'il g£re, au moyen d'une interface logique permettant 
la definition du format des requfites de haut niveau 6mises par les applications et d'un 
logiciel de traduction assurant le traitement de ces requites. 

De preference, le terminal suivant ('invention comprend une ou plusieurs des 
10 caracteristiques suivantes, £ventuellement combines : 

- ledit dispositif d'ex£cution du logiciel filtre comprend des premiers moyens 
d* identification et/ou d'authentifi cation de ladite application implant£e dans ladite unite ou 
de Porigine desdites requ&es £mises par ladite application ; 

- ledit dispositif de traitement de donnees pour Pex^cution dudit logiciel filtre comprend 
15 des moyens de verification de Pintegrite des donnees refue de ladite application ; 

- ledit dispositif de traitement de donnees pour I 'execution dudit logiciel filtre comprend 
des moyens centralises de contrdle des conditions d'utilisation des services du dispositif 
personnel de s£curit£, en fonction de ladite application et/ou dudit utilisateur ; 

- ledit dispositif de traitement de donnees pour I'exeeution dudit logiciel filtre comprend : 
20 • des moyens pour commander le chargement securise dudit logiciel filtre dans 

ladite m^moire programmable, via Pun desdits premiers ou troisifemes moyens 
d'interface, ^ partir d'une entity ext£rieure audit module, et 
• des premiers moyens de contr6le d'acc£s pour n'autoriser ledit chargement dudit 
logiciel filtre qu'en reponse k au moins une condition predefinie ; 
25 - le terminal comprend des deuxtemes moyens d'authentification desdits premiers 
moyens de traitement de donnees par lesdits deuxi&mes moyens de traitement de donnees ; 

- le terminal comprend des troisi£mes moyens d'authentification desdits deuxiemes 
moyens de traitement de donnees par lesdits premiers moyens de traitement de donnees ; 

- le terminal comprend un premier canal de communication entre lesdits premiers et 
30 deuxiemes moyens de traitement de donnees et des premiers moyens de securisation dudit 

premier canal de communication ; 

- le terminal comprend des quatri£me moyens d'authentification dudit module terminal 
par ledit utilisateur, ind£pendamment de ladite carte ; 

- lesdits quatri&nes moyens d'authentification comprennent des moyens de calcul, par 
35 lesdits premiers moyens de traitement de donnees, et de presentation audit utilisateur, via 
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lesdits deuxi&me moyens d'interface, d'un mot de passe connu dudit utilisateur et calcuie sur 
la base d'au moins un premier parametre secret stocke dans lesdits premiers moyens de 
traitement de donnees ; 

- le terminal comprend des cinquiemes moyens d'authentification conjointe dudit module 
5 terminal et de ladite carte par ledit utilisateur ; 

- lesdits cinquiemes moyens d'authentification comprennent des moyens de calcul, par 
ledit dispositif d'execution dudit logiciel, et de presentation audit utilisateur, via lesdits 
deuxiemes moyens d'interface, d'un mot de passe connu dudit utilisateur et calculi sur la 
base d'au moins un deuxieme et un troisi&me parametres secrets stockes respectivement 

1 0 dans lesdits premiers et deuxiemes moyens de traitement de donnees. 

Selon une premiere forme de realisation de I'invention, le module terminal est 
constitue par un ordinateur personnel et ladite memoire programmable est constitute par le 
disque dudit ordinateur, ledit logiciel filtre est execute sur I'ordinateur personnel ou bien 
dans un deuxieme mode d'execution, ladite memoire programmable est implantee sur un 
15 serveur s6curis£ relie k I'ordinateur personnel, la partie du logiciel filtre devant etre protege 
etant executee sur ledit serveur securise. 

Selon une deuxieme forme de realisation de ['invention, le module terminal est un 
dispositif, tel qu'un lecteur dedie de carte k circuit integre, auquel cas ledit dispositif 
personnel de s£curit§ est une carte k circuit integre, ou un ordinateur personnel. Ce mode de 
20 realisation se difference du precedent par le fait que ladite memoire programmable est 
integr£e dans un microprocesseur securise, ledit logiciel filtre etant execute dans ledit 
microprocesseur securise. Le module terminal dedie peut eventuellement etre portable. 

Selon les modes d'execution de cette deuxieme forme de realisation de ('invention, la 
memoire programmable pour le chargement et le stockage du logiciel filtre peut etre 
25 disposee dans le dispositif personnel de security ou dans le module terminal. 
Dans ce dernier cas : 

- le module terminal peut comporter un seul microprocesseur pour ('execution du 
logiciel filtre et le pilotage des interfaces, ou bien deux microprocesseurs remplissant 
respectivement I 'une et I 'autre de ces deux fonctions. 
30 - de preference ledit logiciel filtre comprend au moins un parametre secret et lesdits 

deuxiemes moyens de traitement de donnees comprennent des seconds moyens de contrfile 
d'acces conditionnels pour n'autoriser ('execution desdits calculs cryptographiques, en 
reponse & des commandes elementaires generees par ledit logiciel filtre, que si au moins une 
seconde condition predefinie, fonction dudit parametre secret est remplie 



WO 99/62037 PCI7FR99/01202 

11 

Selon d'autres caracteristiques de Pinvention, lorsque le module terminal comporte 
deux microprocesseurs pour I 'execution du logiciel filtre et le pilotage des interfaces : 

- le terminal comprend un deuxieme canal de communication entre lesdits premiers 
moyens logiciels de pilotage des moyens d'interface et ledit deuxteme microprocesseur et 

5 des deuxtemes moyens de securisation dudit deuxieme canal de communication ; 

- lesdits deuxiemes moyens de securisation comprennent des moyens de chiffrement 
et dechiffrement, par lesdits premiers moyens logiciels de pilotage des moyens d'interface et 
ledit deuxieme microprocesseur, des donnees transmises sur ledit deuxieme canal de 
communication, sur la base d'au moins un cinquteme parametre secret memorise dans 

1 0 lesdits premiers et deuxiemes moyens de traitement de donnees ; 

- lesdits deuxiemes moyens de securisation comprennent des premiers moyens 
physiques de protection dudit deuxieme canal de communication contre les intrusions. 

Differents modes de realisation de Pinvention seront maintenant droits en se referant 
aux dessins annexes, en particulier des modes de realisation dans lesquels le logiciel filtre est 
15 charge et execute dans le terminal de manure k garantir k la fois son origine, sa 
confidentiality et son integrite, ce logiciel pouvant aussi authentifier I'origine des requites 
qui lui sont envoyees, si la confiance dans les interfaces avec Putilisateur, c'est-S-dire I'ecran 
et le clavier, ne peut etre garantie. 

- la Figure 1 est un schema illustrant I'architecture fonctionnelle d'un systeme pour la 
20 mise en oeuvre de transactions securis£es au moyen d'un terminal selon Pinvention ; 

- la Figure 2A presente une premiere forme de realisation de Pinvention ou le terminal 
est un ordinateur personnel couple & une carte k circuit integre par un lecteur, ^application 
pouvant etre elle meme implantee sur I'ordinateur personnel ou sur un serveur distant. 

- la Figure 2B decrit I'architecture fonctionnelle d'une variante d'execution de la 
25 premiere forme de realisation de ['invention, dans laquelle I'ordinateur personnel servant de 

terminal est en liaison avec un serveur de securite sur lequel est implante le logiciel filtre ; : 

- la Figure 3 presente un systeme de transaction mis en oeuvre grace & un terminal 
selon une deuxieme forme de realisation de ('invention, qui peut etre un produit dedie relie 
en tant que peripherique ci un ordinateur personnel ou directement k un serveur ou bien 

30 construit autour d'un ordinateur personnel ; 

- la Figure 4A est un schema bloc de I'architecture materielle des circuits 
electroniques d'un premier mode d'execution du terminal de la figure 3 ; 

- la Figure 4B est un schema fonctionnel illustrant une premiere configuration 
d'architecture logicielle du terminal de la figure 4A ; 
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- la Figure 4C est un schema fonctionnel similaire k celui de la figure 4B presentant 
une seconde configuration d "architecture logicielle du terminal de la figure 4A ; 

- la Figure 5 est un schema bloc de ['architecture materielle des circuits electroniques 
d'un deuxi&me mode d'execution du terminal autonome de la figure 3 ; 

5 - la Figure 6 est un schema bloc de I 'architecture materielle des circuits Electroniques 

d'un troisi&me mode d'ex&rution du terminal autonome de la figure 3 ; 

- la Figure 7 est un schema illustrant ('architecture logicielle conventionnelle d'une 
carte a micro-circuit ; 

- la Figure 8A est un schema illustrant 1'architecture logicielle d'un systeme de 
1 0 transaction comprenant le terminal de la figure 4A ; 

• la Figure 8B est un schema illustrant I'architecture logicielle d'un systeme de 
transaction comprenant le terminal de la figure 6 ; 

- la Figure 9 est un diagramme illustrant la mise en oeuvre d'une application de 
commerce Electronique au moyen d'un systeme selon I'invention ; et 

15 - la Figure 10 est un organigramme illustrant le processus de telechargement d'un 

programme dans une memoire reprogrammable du module terminal de la figure 4A ou 5, 
ou d'une carte k micro-circuit connects k celui-ci ; 

En se referant k la figure 1, un systeme de mise en oeuvre de transactions s6curis£es 
comprend un module terminal 1 de lecture d'une carte k circuit integr6 31 ou equivalent Le 

20 module terminal 1 comprend un filtre F constitu£ d'un module logiciel traitant des requetes de 
haut niveau emises par des foumisseurs de services applicatifs FAp extemes au module terminal 1 
au moyen d'une interface logique F-API, et des interfaces utilisateur telles qu'un ecran d'affichage 
4 et un clavier 5 permettant la lecture et Introduction de donnees par un utilisateur. II comprend 
£galement un lecteur ou interface de communication 6 avec une carte k micro-circuit ou tout 

25 dispositif de s^curite equivalent personnel k I'utilisateur, du type jeton (token), * JavaRing " 
(produit de la societe SUN), u iButton " (produit de la society Dallas Semiconductor Corporation), 
jeton logiciel (soft token), ainsi que des interfaces de communication avec au moins un 
foumisseur de services applicatifs FAp qui peut, par exemple, &tre implants sur un ordinateur 
personnel PC et/ou sur un serveur Sap , I'echange de donnees s'effectuant alors via un reseau R 

30 de transmissions de donnees ou de telecommunications. 

Le module terminal 1 peut §tre un terminal dedi£ ou Gtre integre dans un ordinateur 
personnel de type PC, ou bien dans un ordinateur-terminal NC d6die aux applications en reseau 
(Network Computer) ou encore dans un dScodeur de reseau de television cable (Set Top Box). 
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Le module terminal 1 peut <§ventuellement Stre utilise en mode autonome, par exemple 
pour lire des informations, telles que le contenu d'un porte-monnaie Slectronique, contenues 
dans une ntemoire de la carte 31 . 

Pour la mise en oeuvre de transactions securisees, le module terminal 1 peut &tre 
5 utilise en mode connects avec un serveur Sap ou en mode non connects, ('application FAp 
6tant alors ex^cutee localement, par exemple sur I'ordinateur personnel PC : Tel est le cas, 
par exemple, lorsqu'un utilisateur doit signer un courrier Slectronique ou des transactions 
qui seront envoy^es & un destinataire. Une telle operation n'implique pas de connexion avec 
un serveur applicatif au moment ou la carte 31 est utilisee. 

10 En mode connects comme repr&ente k la figure 3 dans le cas d'un module terminal 1 

dedte, celui-ci peut §tre connecte au serveur Sap sur lequel est implante ^application FAp 
. par Tintermediaire de I'ordinateur PC et d'un reseau R tel qu'lnternet, ou par I' intermediate 
du r6seau tetephonique R via un modem MO ou une liaison DTMF avec un combine 
telephonique CT. Certaines transactions, telles que le rechargement d'un porte-monnaie 

15 6lectronique dans la carte 31, peuvent nScessiter un echange bidirectionnel de donnees 
avec le serveur Sap et sont, par consequent, plus ergonomiques en mode connecte. 

La mise en oeuvre d'une transaction s6curis6e avec un module terminal 1 et une carte 31 
implique que des requetes logicielles de haut niveau (par exemple des requites de signature, 
d'authentification , etc... qui doivent fitre traitees de mantere k satisfaire les objectifs de s&rurite 

20 .requis du programme applicatif) soient transmises du programme applicatif implante par 
exemple dans le serveur Sap (mode connect^) ou dans I'ordinateur personnel PC ou NC k la 
disposition de I'utilisateur (mode non connecte, par exemple signature de courrier 
6lectronique), au fiitre F assurant le pilotage des moyens de s&rurite. Ce filtre F effectue le 
traitement de ces requites au moyen d'un logiciel de traduction, s'assurant ainsi que 

25 I'application ou tout autre logiciel de type virus ne peuvent avoir un acc£s direct aux fonctions 
cryptographiques de la carte ^ circuit integte 31. Le traitement des requites de haut niveau 
comprend la traduction de ces requites en une commande 6l6mentaire ou une sequence de 
commandes elementaires qui sont executees par le dispositif personnel de s6curite. Les 
requites de haut niveau sont formulas independamment de la configuration materielle et/ou 

30 logicielle du dispositif personnel de s6curite, c'est-£-dire qu'elles ne sont pas formulees 
directement en fonction du dispositif personnel de s^curite. 

Les requites de haut niveau contiennent des informations qui sont liees sp§cifiquement 
au processus qui sera execute par le logiciel filtre. Selon un exemple simple, une requete de 
haut niveau peut comprendre une commande 6lementaire unique i transmettre au dispositif 

35 personnel de s6curite, par exemple un APDU ("Application Protocol Data Unit"), dans le cas 
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d'une carte k microcircuit, attache k un code MAC d 'authentication de message qui perrnettra 
au logiciel filtre F de verifier I'origine et I'integrite de cette requite avant d'envoyer !a 
commande el^rnentaire au dispositif personnel de securite. Selon un exempie plus complexe, 
tel qu'une requite de signature d'un document, la requ&e de haut niveau sera transform^ par 
5 le filtre F en une sequence de cornmandes elementaires envoyees au dispositif personnel de 
security et eventuellement k interface utilisateur. Ainsi, selon cette definition etdu faitqu'elles 
contiennent des informations spScifiques devant Stre decodees par le filtre F independamment 
du dispositif personnel de security les requites de haut niveau sont dites etre independantes 
du dispositif personnel de securite. 
10 Le filtre F repond aux objectifs de securite recherches dans la mesure ou le logiciel de 

traduction qu'il comporte verifie I'identite de ('application emettant les requites de services 
(ou directement I'origine des requites) et est implante de maniere k garantir I'integrite et la 
confidentiaiite des operations et donnees elementaires mises en oeuvre pour repondre aux 
requites de sen/ices. 

15 Un logiciel de traduction est un logiciel configure pour un type de carte k micro-circuit 

et traduit une requSte de haut niveau refue d'un logiciel duplication en une commande 
eiementaire ou une sequence de cornmandes elementaires executables par les cartes k 
micro-circuit et/ou une sequence d'echanges de donnees avec I'utilisateur. 

Les requetes de haut niveau sont une liste de cornmandes utilises par les programmes 

20 applicatifs pour faire appel aux services de securite necessaires pour identifier et authentifier la 
personne realisant la transaction et garantir I'origine, I'integrite et eventuellement la non- 
repudiation de la transaction. Une requite de haut niveau provenant d'une application (se 
trouvant sur un serveur ou sur I'ordinateur personnel PC ou NQ peut etre caract6risee par un 
ou plusieurs des points suivants : 

25 - elle est independante des moyens de base (moyens cryptographiques par exempie) 

mis en oeuvre pour satisfaire k sa demande et contient des informations specifiques devant 
etre traitees par le filtre F. Reciproquement, plusieurs applications peuvent utiliser le meme 
fournisseur de services de securite, faisant alors appel k la meme interface logique F-API 
definissant ces requ£tes. 

30 - le traitement de la requete permet de lier la transaction de maniere certaine k 

I'utilisateur effectuant la transaction k I'aide d'au moins un parametre secret, fixe ou variable, 
stocke dans la carte k circuit integre de I'utilisateur. 

- elle comporte eventuellement une information ou des informations permettant au 
logiciel filtre F de verifier son origine et son integrite. L'authentification peut se faire k I'aide 
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d'un code de type " Message Authentication Code ou MAC " ou bien de type " signature 
electronique * associe h la requite. 

- dans le cas 0C1 la transaction n'est pas saisie par I'utilisateur sur le module terminal 
lui-mSme, la requite contient 6ventuellement 1'information n^cessaire pour permettre £ 
5 I'utilisateur de verifier, s'il le souhaite et si le module terminal supporte cette option, les 
donn£es essentielles de la transaction. 

L'interface logique F-API permettant I'echange des requetes de security de haut niveau 
entre les applications et le logiciel de traduction du filtre F peut Stre standardise de manure k 
§tre commune k differents programmes applicatifs. Ainsi, la requite de type " Signature * peut 
10 etre. utilise par une messagerie electronique ou par un logiciel d'achat. II est ainsi possible de 
changer ['application tout en conservant le fournisseur de services de sScurite ou 
reciproquement de remplacer le fournisseur de services de s6curit<§ sans modifier I'applicatidn. 

Afin de garantir I'int6grit§ de la chaine de confiance entre ('application et la carte, le 
logiciel filtre F de traduction identifie, voire authentifie I'origine et .('integrity des requites 
15 qu'il recoit Differentes methodes peuvent 6tre envisagees pour, identifier ('application 
£mettant les requStes : 

- un code d'identification peut etre int6gr6 dans la requ£te elle- meme puis vgrifie par le 
logiciel filtre £ partir des informations qu'il contient ou qui peuvent &tre stockees dans la 
carte k circuit int6gr£ ; 

20 - le meme but peut fitre atteint en comparant le r&ultat d'une operation de hachage 
execute par le logiciel filtre sur le logiciel applicatif 6mettant la requgte avec un r&ultat 
pr£alablement stocks dans la carte par exemple. Cette derntere solution est particulidrement 
adaptee au cas ou ('application est implantee sur le PC de I'utilisateur ; 

- I'authentification peut Sgalement &tre r£alis£e en associant £ la requite un code de type 
25 "MAC calculi £ partir du contenu de la requ&e et d'une cl6 secrete partag^e entre 

I'application et le logiciel filtre. Un principe Equivalent peut §tre utilise kvec une signature de la 
requite calculEe avec les mSmes informations et une cl6 privee connue de ['application, la 
signature &ant v£rifiee avec la cl6 publique correspondante connue du logiciel filtre. 

La figure 2A dEcrit une premiere forme de realisation pour laquelle le module terminal 

30 1 est un ordinateur personnel PC 102, la liaison avec la carte k circuit integrE 31 s'effectuant 
au moyen d'un lecteur 6 connecte ou int£gr6 £ I'ordinateur PC 102. L'ordinateur personnel 
102 comprend des interfaces d'entr£e/sortie 102a avec le lecteur 6 et le serveur Sap. Suivant 
la nature du lecteur connects au PC, les elements d'interface avec I'utilisateur peuvent fitre le 
clavier et I'ecran du PC lui-m&me, ou bien un clavier et/ou un afficheur de type LCD par 

35 exemple implante sur le lecteur. Dans ce mode de realisation, le filtre F est implants et 
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execute sur I'ordinateur PC 102. Le fiitre F, et done le logiciel de traduction qu'il contient, 
peut aiors etre stocke sur le disque dur HD 102b de I'ordinateur personnel 102. Pour Stre 
execute par I'unite de calcul ou microprocesseur 102c du PC, le logiciel fiitre est ensuite 
charge dans la memoire vive RAM 102d de I'ordinateur personnel 102. 
5 Le disque dur d'un ordinateur PC etant difficile k proteger, le logiciel fiitre F, ou tout 

au moins la partie sensible de ce logiciel, peut etre chiffre. Pour cela il peut etre decompose 
en au moins 2 modules : un module de chargement/dechiffrement Fed et un deuxieme 
module correspondant au logiciel fiitre lukngme chiffre, Fchi. Le premier module permet le 
chargement du deuxieme module en memoire RAM, son dechiffrement, puis le lancement 

10 de son execution. En se referant k la Figure 2A, le module logiciel dechiffrS et charge en 
RAM est nomme Fdec. 

L'utilisation d'un langage de programmation tel que Java, par des mecanismes de 
security intrins^ques au langage lui-meme, permet de renforcer la protection du logiciel 

Une autre m&hode de verification de I'integrite du logiciel fiitre est de faire signer le 

1 5 deuxieme module par uhe autorite garante du contenu du logiciel fiitre au moyen d'une cle priv£e 
conserve secrete par cette autorite. Le premier module de chargement effectue alors, 
simultanement k I'operation de dechiffrement, une operation de hachage sur ie deuxieme module et 
verifie la signature de ce module au moyen de la cle publique associee k la cle privee de I'autorite. 
L'ensemble des operations decrites dans les paragraphes precedents implique 

20 ^utilisation de cl6s sur lesquelles reposent la securite de ['application. Ces des peuvent etre 
caches dans le module de chargement, stockees dans le lecteur 6, ou bien stockees dans la 
carte k circuit integre 31 elle-mfime. Un autre mode de realisation possible consiste k 
implanter le module de dechiffrement et de verification d'int^grite dans le lecteur 6. 

L'objet de invention est de s'assurer qu'un pirate ne puisse pas utiliser la carte k 

25 circuit integre d'un utilisateur k son insu, par exemple en modifiant le logiciel fiitre pilotant 
la carte ou le logiciel application/ ou bien en implantant un logiciel virus qui court- 
circuiterait ('application ou le logiciel fiitre mis en place. Le mode de realisation decrit 
prgcedemment et ses variantes repondent k ces risques, en permettant la verification: 
- de I 'integrity du logiciel fiitre et 

30 - de I'origine et de I'integrite des commandes envoy£es k la carte k travers le lecteur 6, en 

les authentifiant k I'aide d'un code de type MAC par exemple. La verification du MAC peut etre 
effectuee par le lecteur 6 ou la carte 31. Une protection equivalente pourrait etre obtenue en 
chiffrant le dialogue entre le logiciel fiitre et le lecteur 6. Un logiciel virus cherchant k court- 
circuiter le logiciel fiitre enverrait done des commandes non authentifiees ou incorrectement 

35 chiffrees au lecteur 6 ou k la carte 31 ; en consequence ces commandes seraient rejetees par le 



WO 99/62037 PCT/FR99/01202 

17 

lecteur ou la carte, empSchant le virus d'arriver k ses fins. Afin qu'un fraudeur ne puisse 
determiner les des utilises sur un terminal en analysant le fonctionnement d'un autre terminal, 
les des utilisees par divers terminaux devront etre diversifiees. 

Les mecanismes de chiffrement et de signature qui peuvent etre envisages pour repondre 
5 au besoin de protection du logiciel filtre sont bien connus des hommes de I'art et reposent sur 
les techniques cryptograph iques existantes exposes, par exemple, dans I'ouvrage de Bruce 
Schneier intitule "Applied Cryptography, Protocols, Algorithms, and Source Code in C" publie 
chez John Wiley and Sons, Inc., 1 994, et qui ne seront done pas decrits en detail ici. 

L'implantation du logiciel filtre dans un ordinateur personnel PC ne permet pas de 

10 garantir le mSme degrS de securite qu'une implantation dans un terminal dSdie pouvant 
offrir des mecanismes de securite materiels supplementaires comme decrit dans les autres 
formes de realisation presentees ulterieurement, ces mecanismes procurant une protection 
physique au logiciel filtre et aux secrets qu'il contient. 

Une variante d'exgeution du mode de realisation de la figure 2A est pr^sente k la 

15 figure 2B. Cette variante met a profit la souplesse et la facilite de connexion d'un ordinateur 
personnel a un reseau. Cette connexion permet en effet le deport d'une partie du logiciel 
filtre, et en particulier des secrets, dans un serveur securise Ssec. 

Dans le cas de la Figure 2B, le logiciel filtre est decompose en deux modules logiciels, 
un module F-PC implante sur I'ordinateur personnel PC 102 et un module F-SE implante sur 

20 un serveur de securite Ssec. La memoire programmable a laquelle il est reference 
pn§c£demment et stockant le logiciel filtre, est done dans cette variante d'execution 
implantee dans le serveur securise Ssec, c'est-£-<lire hors d'atteinte d'utilisateurs non 
autorises. De m§me, le logiciel filtre, ou tout au moins la partie sensible du logiciel filtre F-SE 
requerant une protection, est execute sur le serveur securise Ssec. 

25 Le module logiciel F-PC implante sur I'ordinateur personnel PC 102 est relie par un 

canal securise CS au serveur de securite Ssec. Ce canal securise est en fait un canal de 
communication chiffre permettant un echange de donnees protege entre les deux modules 
logiciels filtre F-PC et F-SE et eventuellement une authentification reciproque des deux 
modules F-PC et F-SE. Ce canal securise peut, par exemple, reposer sur des protocoles de 

30 communication bien connus tels que SSL. 

L'etablissement de ce canal securise CS permet done au premier module logiciel filtre F-PC 
de transmettre au deuxteme module logiciel filtre F-SE, les requfites regues de I'application FAp & 
travers ['interface logique F-API, ainsi que les informations liees k I 'identification de ('application 
emettant ces requfites. Ce deuxieme module logiciel F-SE va ensuite, aprfcs avoir verifie les 

35 informations relatives k Papplication et, en fonction de ^application et eventuellement des 
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droits de I'utilisateur, traduire ces requites en une suite de commandes destinees a la carte a puce 
3 1 et au pilotage des echanges de donnees avec I'utilisateur. Ces commandes crees par le module 
F-SE sont ensuite envoyees au premier module F-PC qui les aiguille vers I'element conceme" : le 
PC lui meme pour ce qui conceme les commandes de pilotage des echanges avec I'utilisateur ou 
5 bien la carte a circuit integrS. Pour que les commandes de pilotage des echanges avec I'utilisateur 
puissent etre executees sur le PC, le PC devra comporter un module logiciel I, dit interpreteur. Ce 
logiciel interpreteur permet I'affichage de messages sur I'ecran 4 et la saisie d'information par 
I'utilisateur sur le clavier 5. Ce module logiciel interpreteur sera plus precisement decrit en regard 
des figures 4B et 4C. 

10 Ce second mode d'execution est bas6 sur les mecanismes decrits a propos du premier 

mode d'execution de la figure 2A en ce qui conceme ^identification de I'application 
(hachage ou signature par exemple) et la protection des commandes envoyees a la carte 
(ajout d'un code de type authentification de message MAC, par exemple). II offre par contre 
un degre de securite superieur dans la mesure ou le module logiciel filtre F-SE assurant la 

15 traduction des requites de haut niveau recues de I'application Fap est execute" dans un 
environnement securise\ Dans le contexte de I'invention, le serveur Ssec est dit securisS s'il 
n'est pas accessible physiquement ainsi que logiquement, c'est dire a travers une connexion 
rGseau, a des personnes non autorisees. 

Ce second mode d'execution de la figure 2B est bien adapts a des applications mises en 

20 oeuvre dans un environnement ferm6 ou privatif contr6l6 par une autorite centrale, car elle 
nexessite un serveur protegg dont I'administration doit etre centralisee. Ce second mode 
d'execution offre de plus la possibility de definir une politique d'acces centralisee aux services 
cryptographiques offerts par la carte a circuit intigrg. Cette politique d'acces peut etre basee sur 
les applications requerant les services de la carte et sur les utilisateurs eux memes. Elle permet, par 

25 exemple, dans la cas d'une entreprise ayant distribue a ses employes ou a ses clients des cartes a 
circuit inte;gre? leur permettant de signer des courriers electroniques ainsi que des transactions 
bancaires, de s'assurer que seuls les utilisateurs autorises pourront signer : ce mecanisme peut etre 
mis en oeuvre grace au canal securisS CS. A chaque requite de signature Smise par une des 
applications considSree comme valide par I'entreprise (la messagerie electronique et le logiciel de 

30 transactions bancaires), le module logiciel F-SE effectuera une demande d'authentification de 
I'utilisateur. Cette demande peut, par exemple, etre effectuee en envoyant un nombre aleatoire, 
challenge ou dtfi via le canal securise" CS a la carte 31. Apres saisie par I'utilisateur de son code 
confidentiel, la carte a circuit int6gr6 calculera un mot de passe dynamique en chiffrant le d6fi a 
I'aide d'une c\i secrete qu'elle contient. Le mot de passe sera ensuite transmis via le canal CS au 

35 module logiciel F-SE. Le module logiciel F-SE, connaissant I'utilisateur et done la cl£ secrete 
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contenue dans sa carte, comparera le mot de passe re?u au mot de passe attendu. Ce mecanisme 
connu sous le nom d'authentification en mode challenge - reponse pennet au module logiciel F- 
SE de valider I'identite de I'utilisateur. Ceci permet done k I'entreprise ayant remis les cartes a 
circuit int^gre aux utilisateurs de s'assuner que seuls les utilisateurs encore autorises peuvent par 
5 exemple signer des transactions bancaires. 

Le serveur Ssec, grace aux moyens s6curis& et centralises qu'il represente, pennet non 
seulement une implantation s6curis6e du logiciel filtre F-SE mais aussi la possibility de mettre en 
place une politique centralist de contr6le de ('utilisation des services de security offerts par la 
carte k circuit integre. Le serveur Ssec permet la mise en place d'une politique centralisee du fait 

10 . qu'un mgme serveur peut etre en liaison avec une plurality des modules logiciels F-PC implantes 
sur les ordinateurs personnels d'une plurality d'utilisateurs. Le serveur Ssec permet ainsi la 
definition et le contrCle centralists des conditions d'utilisation des services de security offerts par 
les cartes remises aux diffenents utilisateurs, en fonction du profit de I'application requerant les 
services et des droits desdits utilisateurs. La mise en place de cette politique centralisee implique 

1 5 done de stocker dans le serveur les informations necessaires, e'est-^-dire les droits des utilisateurs 
d'utiliser tel service de securite en liaison avec telle application. 

Ce second mode d'execution de la figure 2B, bien adapts aux environnements prives, 
est par contre difficilement applicable k des applications ouvertes pour lesquelles la mise en 
place d'un serveur central securise Ssec n'est pas envisageable. 

20 La Figure 3 illustre un module terminal reprenant des principes d'architecture 

fonctionnelle similaires k ceux de la Figure 2B dans une forme de realisation differente, ne 
necessitant pas de serveur centralist. Le module terminal selon la deuxitme forme de 
realisation de la Figure 3 presente un trts haut degre de security lui permettant ainsi 
d'assurer directement la protection locale du logiciel filtre F. 

25 Dans le cas de la figure 3, le module terminal 1 se presente sous la forme d'un boitier, 

portable ou non, dont une face porte I'tcran d'affichage 4 et le clavier 5 et dans lequel sont 
implantts des circuits electroniques, de preference de manitre telle que ceux-ci soient 
inaccessibles depuis Pexterieur. Le boTtier 1 cpntient le lecteur 6 et presente une ouverture 
de reception de la carte k micro-circuit 31 dans le lecteur 6. Le mode d'execution decrit en 

30 reference aux Figures 3, 4A, 4B et 4C ne doit pas etre consider comme se limitant k un 
terminal dedie. La description qui suit peut tout k fait etre appliquee k un terminal construit 
autour d'un ordinateur personnel de type PC ou NC. 

Selon un premier mode d'execution, illustre k la figure 4A, de cette deuxi^me forme 
de realisation du module terminal de la figure 3, les circuits electroniques du module 

35 terminal 1 sont organises autour d'un microcontrOleur standard 2 et d'un microprocesseur 3 
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securis<§, qui sont connects entre eux par une liaison et implants de manure permanente 
dans le boitier du module 1 . En variante, le microprocesseur 3 peut etre enfichable sur le 
module 1 au moyen d'un connecteur 41 represents en traits interrompus a la figure 4A. II est 
d£crit ici un mode d'exScution gSnerique base sur un microcontrOleur standard. Dans un 
5 mode d'execution particulier qui sera dScrit ulterieurement, le microcontrdleur 2 peut en fait 
etre un PC 102 du type de celui presents dans la Figure 2B. 

Le microcontrdleur standard 2 comprend une unite de traitement 2a, de la memoire 
temporaire (RAM) 2b, et de la memoire permanente (ROM) 2c. II s'agit de preference d'un 
microprocesseur "monochip" dont le programme est masqu<§ dans la memoire permanente 2c 

10 et qui integre dans un mfime circuit integr6 des moyens de gestion ou pilotage d'interfaces 
standards, I'unite de traitement 2a et les memoires temporaire 2b et permanente 2c. 

Les interfaces ou p£riph«§riques gStees par le microcontrfileur 2 comprennent notamment 
l'<kran 4 d'affichage de donne§es, par exemple k cristaux liquides, le clavier 5 pour ('introduction 
de donnees par un utilisateur, le lecteur 6 de carte k microcircuit, une interface 7 de liaison 

1 5 exteme, par exemple du type RS 232 ou PCM-CIA, une interface 8 de liaison par infrarouge, et un 
dtspositif DTMF 9 pour la transmission de donnees sur une ligne tel£phonique. 

Les composants du module 1 comprennent Sgalement une horloge 10 et une source 
1 1 d'alimentation electrique des differents circuits et composants du module 1. La source 1 1 
d'alimentation electrique peut Stre constitute par des piles ou une batterie si le module 1 est 

20 portable et autonome. 

La tache du microcontrdleur standard 2 est de gener I'environnement, c'est-St-dire de piloter 
les interfaces 4-9 et I'horloge TO, ainsi que la source d'alimentation 1 1 pour alimenter s<§lectivement 
le microprocesseur s£curis£ 3 en £nergie electrique dans le cas d'un module 1 autonome. 

Le microcontrdleur standard 2 nEcessite ainsi peu de puissance de calcul, peu de 

25 memoire temporaire (RAM) et pas de memoire semi-permanente (EPROM ou EEPROM). Le 
microcontrdleur 2 est protege en 6criture du fait que ses programmes (pilotage d'interfaces 
et, comme d£crit dans la suite, interpreter, gestion des horloges et de Talimentation 
electrique, etc..) sont masques en memoire permanente 2c. Comme cela apparaitra dans la 
suite, le microcontrdleur standard 2 peut 6galement contenir un ou plusieurs param£tres 

30 secrets, sur la base desquels il peut Stre authentifte par le microprocesseur securis£ du 
module terminal et/ou d'une carte k circuit integre. Ces secrets doivent done Stre proteges en 
lecture et en §criture. lis seront de preference stockes dans la memoire temporaire (RAM) 
d'un microprocesseur "mono chip", qui n'est accessible ni en ecriture, ni en Venture depuis 
I'exterieur. Le microcontrdleur standard 2 peut egalement etre pourvu de fonctions de 
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securite compl<§mentaires, par exemple pour interdire des fraudes telles que I'affichage de 
donnSes differentes de celles provenant du microprocesseur 3, 

II s'agit par consequent d'un microcontrdleur d'un faible cout et ayant une faible 
consommation electrique, qui est particulterement adapts k un produit portable. Ce 
5 microcontrdleur peut gtre par exemple du type MSM 631 80 de la Society OKI. 

De preference, deux horloges sont prevues en 10 : une horloge k frequence basse 10a, 
par exemple de frequence 32,368 KHz et une horloge k frequence <§iev£e 10b, pouvant aller 
de 1 MHz k 12 MHz par exemple Le microcontrdleur 2 commande la connexion de son 
horloge systeme sur Tune ou I'autre de ces deux horloges. 

10 L'horloge lente 10a cadence un dispositif de temporisation 2d du microcontrdleur 2 

avec une periode de 0,5 s pour realiser une horloge temps r£el dans le module 1. L'unite de 
traitement 2a peut £galement fonctionner k Paide de l'horloge lente 10a pour les fonctions 
ne n^cessitant pas de vitesse de calcul : dans ce cas l'horloge systeme du microcontrdleur 2 
est connects sur l'horloge lente 10a et l'horloge rapide 10b est arr&ee. Ce mode de 

15 fonctionnement permet de limiter la consommation electrique du module 1, ce qui est 
avantageux si celui-ci est portable et aliments par une pile electrique. 

Le microprocesseur 3 s£curis£ en lecture et en Venture comprend une unite centrale 
3a et des memoires temporaire (RAM) 3b et permanente (ROM) 3c, ainsi qu'une memoire 
semi-permanente reprogrammable Slectriquement (EEPROM ou Flash RAM par exemple) 3d 

20 pour le stockage, entre autres, des programmes duplication du module 1 . 

Ce microprocesseur securise 3 est du type de ceux utilises dans les cartes k micro 
circuit et il presente un nombre limits d'entrees et de sortie, ses bus internes etant 
inaccessibles depuis I'extSrieur. De par sa fabrication, il integre d'autres mecahismes de 
securrte propres k ce type de microprocesseur et bien connus des specialistes de la 

25 technique, tels que matrice de securite, brouillage de memoire, contrdle de la frequence 
d' horloge, contrdle de la remise k zero (RESET), etc... 

Grace.au fait que le microprocesseur 3 poss^de une memoire semi-permanente 3d, il 
est possible d'y charger depuis I'exterieur, par exemple k partir d'un serveur ou d'une carte k 
micro-circuit, un ou des programmes duplication. II est ainsi possible, en fonction des 

30 besoins, de faire 6voluer la ou les applications (contrdle d'acc^s, transaction financiers et/ou 
commerciales, porte-monnaie electronique, etc..) auxquelles est destine le module 1. II est 
egalement possible, si la taille de la memoire semi-permanente 3d le permet, d'y implanter 
de nouvelles applications au cours de son utilisation. 

Selon la version choisie, le microprocesseur securis£ 3 peut assurer le calcul de 

35 fonctions cryptographiques requ^rant des calculs importants mis en oeuvre dans les 
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algorithmes asymetriques de type RSA ou DSA, ou bien mettre en ceuvre des algorithmes 
plus simples, par exemple du type DES. 

Le microprocesseur securise 3 peut etre, par exemple : 

- un microprocesseur SIEMENS SLE44C160S, non cryptographique, dote de 14 Ko de 
5 memoire ROM et de 1 6 Ko de memoire EEPROM ; 

- un microprocesseur SGS THOMSON ST1 6CF54A cryptographique dote de 1 6 Ko de 
memoire ROM, de 4Ko de memoire EEPROM et de 480 octets de memoire RAM ; 

- un microprocesseur PHILIPPS P83C858 cryptographique dote de 20 Ko de memoire 
ROM et de 8 Ko de memoire EEPROM. 

10 Le microprocesseur securise 3 est connecte, d'une part par la liaison 12 au 

microcontrfileur standard 2, d'autre part par des liaisons 1 3 et 14 & ['interface externe 7 et au 
lecteur 6 de carte k micro-circuit par I' intermediate de commutateurs-adaptateurs d'interface 
15 et 16 respectivement. Les commutateurs-adaptateurs 15 et 16 sont commandes par le 
microcontrfileur standard 2 via des liaisons 17 et 18 respectivement. 

15 Le microcontrdleur standard 2 comprend un programme d' interpretation ou 

interpreter 20 (Fig. 4B et 4C) stocke dans la memoire ROM 2c et permettant k celui-ci 
d'executer des commandes g£n£rees par le logiciel de traduction des requetes de haut 
niveau faisant partie du ou des programmes duplication, comme cela sera decrit dans la 
suite. Cet interpreter 20 permet ainsi au(x) programme(s) d'application stocke(s) dans le 

20 microprocesseur securise 3 de piloter les interfaces 4-9 via la liaison 12. Cependant, le ou les 
programmes d'application peuvent etre localises et executes ailleurs que dans le 
microprocesseur 3 securise en lecture et en Venture, par exemple dans une carte a micro- 
circuit 31 ins6r£e dans I'interface 6, telle qu'une carte adaptee pour supporter des 
m^canismes de telechargement et d'execution des applications comme decrit dans la norme 

25 NF EN 726-3 intitule "Cartes k circuit int£gre et terminaux pour les telecommunications. 
Partie 3 : Specifications de la carte independantes des applications". 

Les programmes d'application peuvent en outre, en fonction des regies de securite 
auxquelles ils sont soumis, etre distribues entre ces differentes localisations. 

Le schema fonctionnel de la figure 4B illustre une premiere configuration 

30 d' architecture logicielle du module 1 de la figure 4A dans laquelle I'ensemble des 

programmes d'application A1, A2, An et des fonctions de securite (calcul de condense, 

algorithmes cryptographiques symetriques tels que DES, triple DES, ou asymetriques tels que 
proposes par RSA) est mis en oeuvre dans le microprocesseur securise 3. 

Les applications nommees ci-dessus et dans la suite de la description A1, A2, An 

35 comprennent au minimum les filtres F1, F2, Fn, et done en particulier les logiciels de 
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traduction des requ&es 6mises par le ou les fournisseurs de sen/ices appticatifs FAp faisant 
partie de I'application principale 54 (Figure 8A). 

Le microcontrOleur standard 2 g£re I'environnement au moyen de differents 
programmes de gestion ou gestionnaires d'interface k savoir : 
5 - un gestionnaire 21 du lecteur ou interface 6 de carte k micro-circuit; 

- un gestionnaire 22 de I'interface 7 de liaison serie ; 

- un gestionnaire 23 du clavier 5 ; 

- un gestionnaire 24 de Pinterface 8 de liaison par infrarouge ; 

- un gestionnaire 25 de I'afficheur 4 ; 

10 - un gestionnaire 26 de Phorloge 10 et de la source d'al (mentation 11; 

- un gestionnaire 27 de I'interface DTMF 9 ; 

- un gestionnaire 28 d'autres interface, dans I'hypothese ou le module 1 comporte une 
ou des interfaces autres que celles representees k la figure 2. 

Ainsi, le microprocesseur securis£ 3 peut piioter les interfaces au moyen de 

15 commandes qui sont interpretees par I'interpreteur 20 et ex6cutees par le microcontrfileur 
standard 2 grace aux gestionnaires 21-28. 

La figure 4C illustre une seconde configuration logicielle du module 1 de la figure 4A 
dans laquelle une ou plusieurs applications Ax et une ou piusieurs fonctions 
cryptograph iques Sx sont stockees dans une memoire reprogrammable 30a d'un 

20 microprocesseur securise 30 d'une carte k micro-circuit 31 . Lorsque la carte 31 est introduite 
dans le lecteur 6, le microprocesseur 30 execute les applications Ax et les fonctions 
cryptographiques Sx, tahdis que d'autres applications et fonctions de security peuvent etre 
residentes dans et mises en oeuvre par le microprocesseur securise 3 du module 1. C'est 
ainsi, par exemple, que le microprocesseur 30 de la carte 31 peut assurer une fonction de 

25 signature 6!ectronique dans l'hypoth£se ou le microprocesseur securis^ 3 n'integre pas un 
processeur de calcul dedte (cryptoprocesseur). Reciproquement, si le microprocesseur 
securise 3 integre un cryptoprocesseur, il est Sgalement possible qu'une application presente 
dans la carte k micro-circuit 31 fasse appel k des commandes cryptographiques du module 
1, commandes qui seront executes par le microprocesseur securisd 3. 

30 Dans cette seconde configuration, qui pour le reste est identique k celle de la figure 4B, 

I'interpreteur 20 joue vis-a-vis du microprocesseur 30 le meme rQle que celui qu'il remplit vis- 
^-vis du microprocesseur securise 3. Le module 1 peut ainsi executer des applications 
differentes selon le type de carte 31 k micro-circuit introduit dans le lecteur 6, par exemple : 
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- une authentication de I'utilisateur dans le cadre d'une transaction bancaire 
(consultation de compte, virement de fonds, etc..) effectuee via une ligne telephonique au 
moyen de I 'interface DTMF 9 ; 

- une consultation du solde d'un porte-monnaie £lectronique, ou le rechargement de 
5 ce porte-monnaie, k partir du module 1, lorsqu'une carte k micro-circuit 31 remplissant la 

fonction de porte-monnaie est introduite dans le lecteur 6. En outre, le module 1 permet de 
gerer plusieurs cartes porte-monnaie differentes : porte-monnaie bancaire, porte-monnaie 
sp^cifique k une collectivity par exemple ; 

- lecture d'un dossier medicalsur une carte medicale ; 

10 - lecture de points de fidelity sur une carte dans laquelle des points de fid6lite sont 

attribues k un consommateur en fonction d'achats effectues, de sa participation k des 
operations de fid£lisation de clientele, etc... 

Le mode d'execution decrit ci-dessus k la Figure 4A ainsi que les configurations 
logicielles presentees dans les Figures 4B et 4C s'appliquent, de maniere analogue, a un 

15 terminal construit autour d'un PC conventionnel equjpe en outre du microprocesseur 
securise 3. Dans ce mode d'execution, le microcontrdleur 2 correspond au PC 102 tel qu'il 
est pr£sente k la Figure 2A, I'unite de traitement 2a correspond au microprocesseur 102c du 
PC, et les m£moires RAM 2b et permanentes 2c correspondent respectivement k la memoire 
RAM 102d et au disque dur 102b. De mgme les entrees / sorties 102a du PC correspondent 

20 aux modules d'interfaces 7, 8 et 12 de la Figure 4A. La connexion entre le microprocesseur 
s£curise 3 et le PC 102 peut gtre une liaison serie ou paraliele, ou bien encore une 
connexion au bus interne du PC, du type PCMCIA, ou une connexion directe sur la carte 
m6re du PC. En variante, le microprocesseur securise 3 peut£tre integre de manure fixe, ou 
amovible via le connecteur 41 , au clavier du PC. 

25 Dans ce cas, le module logiciel interpreter 20 ainsi que les modules logiciels de 

gestion des periph£riques 21 k 28 sont implants et executes sur le PC. L'architecture 
fonctionnelle de ce mode d'execution est equivalente k celle presentee ct la Figure 2B, le 
module interpr&eur 20 ainsi implants sur le PC assurant le m&me r&le que le module 
interpr£teur I de la Figure 2B : il execute les commandes de pilotage des ^changes avec 

30 I'utilisateur revues du logiciel filtre F lui-m&me implant^ de mani&re securise dans le 
microprocesseur 3 (Figure 4B) ou la carte a circuit integre 30 (Figure 4C). 

Le schema de la figure 5 illustre un deuxteme mode d'execution de la deuxteme forme 
de realisation de Pinvention, dans lequel les circuits electroniques du module terminal 1 sont 
organises autour d'un seul microcontrdleur 29 rempla^ant le microcontrdleur 2 et le 

35 microprocesseur 3 et pouvant offrir le meme type de protection physique et logique que les 
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microprocesseurs congus pour les cartes k circuit integre. Ce microcontrdleur g£re I'ensemble 
des moyens d'interfaces 4-9 du module terminal. II comporte une unite de traitement 29a, une 
memoire temporaire (RAM) 29b, une memoire permanente (ROM) 29c et une memoire semi- 
permanente (EEPROM) 29d permettant le stockage du logiciel de traduction. L'unite de 
5 traitement 29a correspond k la fois k l'unite 2a de traitement de donnges permettant le pilotage 
des interfaces et k l'unite 3a de traitement permettant l'ex6cution du logiciel de traduction. De 
m&me que pr&tedemment, le module terminal 1 peut Stre construit autour d'un ordinateur 
personnel PC 102 auquel serait connects au bus interne un microcontrdleur securise 29 
pilotant ainsi directement f'6cran d'affichage 4 et le clavier 5 du PC. 

10 Dans une variante de realisation, la memoire dans laquelle est stockee le logiciel de 

traduction des requites de haut niveau, memoire volatile de type RAM avec une alimentation de 
sauvegarde ou semi-permanente (EEPROM ou Flash RAM), peut §tre exteme au microcontrdleur 
29. Dans ce cas, le logiciel de traduction peut §tre chiffre et signe, ou protege par un code de type 
MAC ("Message Authentication Code") de man fere k assurer k la fois son integrite et sa 

15 confidential ite. Le logiciel est lu par le microcontrdleur 29, dechiffre puis execute. 

Selon un troisteme mode d'ex<§cution, represent^ k la figure 6, de la deuxieme forme 
de realisation de ^invention, le module terminal 101 est d<§pourvu de microprocesseur 
s<§curis£ 3. Sur cette figure 6, ies memes nunrteros de reference qu'k la figure 4A ont &e 
conserves pour designer les mgmes Elements. Le microcontrdleur 2 pilote I 1 interface 6 et le 

20 commutateur-adaptateur 15 pour permettre la connexion du microprocesseur securise 130 
d'une carte k micro-circuit programmable 131 ptesente dans I* interface 6 avec I'interface de 
liaison externe 7. Dans ce cas, I'ensemble des applications A et des fonctions 
cryptographjques C sont m6moris§es dans une memoire semi-permanente 130a (EEPROM 
ou Flash RAM) du microprocesseur s6curis£ 130 de la carte k micro-circuit programmable 

25 131, et mises en oeuvre parce dernier comme decriU la figure 4C k propos des applications 
Ax et des fonctions cryptographiques Cx. - . 

Dans les exemples droits pr6c6demment, dans un but de simplification, le 
microprocesseur 30, 130 de la carte k circuit integte ainsi que le microprocesseur securise 3 
6ventuellement implante dans le module terminal comporte un seul port de communication. 

30 Ceci implique que dans ces exemples, les ^changes entre les differentes entites, k savoir l'unite 
6lectronique 154 (figure 8) contenant I'application principale, le microprocesseur securise 3 et 
le microprocesseur 30, 130 de la carte circuit integte se font k travers le microcontrdleur 2 ou 
29 du module terminal. Ces descriptions ne doivent pas Stre considerees comme limitatives : 
d'autres mises en oeuvre peuvent Stre envisages dans le cadre de la presente invention. En 

35 effet, les microprocesseurs s£curis£s de carte k circuit integre actuellement disponibles, 
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utilisables pour la carte elle mSme (microprocesseur 30, 130) ou dans le module terminal 
(microprocesseur 3), peuvent comporter deux ports de communication. Differentes formes de 
realisation optimisant les flux de communication sont done ais^ment envisageables avec ce 
type de microprocesseur. Dans le cas de la figure 4C, par exemple, un des ports de la carte k 
5 circuit int6gr6 31 peut §tre dedie au pilotage de ('interface utilisateur et done relie au 
microcontr6leur 2, I'autre port 6tant relie k I'unite electronique comportant ('application 
principale moyennant une adaptation d'interface appropriee. 

Suivant une caracteristique importante de I'invention, un logiciel filtre est implante 
dans la memoire reprogrammable EEPROM assoctee au microprocesseur s^curise 3 ou 29 
10 du module terminal 1 et/ou au microprocesseur securise 30, 130 de la carte 31, 131. Ce 
logiciel filtre traduit de manure connue les requfites de haut niveau en provenance du 
serveur Sap ou de I'ordinateur personnel PC en sequences de commandes elementaires 
executables par ces microprocesseurs (commandes qui sont notamment definies par la partie 
4 de ia norme ISO 7816^). En outre, suivant ('invention, ce logiciel filtre traduit ces requetes 
15 de haut niveau en sequences d'6changes de donn£es entre le module terminal 1, 101 et un 
utilisateur via les moyens d'interface tels que Pafficheur 4 et le clavier 5. 

Cette solution offre I'avantage de r&Juire considerablement le debit de donnees 
6chang6 entre le module terminal 1, 101 et le serveur Sap ou le PC, mais requiert une 
implantation s6curis£e du logiciel de traduction pour empgeher que les instructions 
20 envoyees k la carte k micro-circuit soient modifies. 

Ce logiciel filtre fait partie integrante de la partie du logiciel d'application implantee 
dans le module terminal 1 et/ou la carte 31, 131 et il est done t£l6chargeable. 

La figure" 7 illustre I 'architecture logicielle conventionnelle d'une carte k micro-circuit 
("smart card"). 

25 Les differentes couches de logiciels sont representees par un bloc 43 qui comprend 

une couche logicielle 44 "protocole de communication" permettant de recevoir des 
commandes. Ces commandes sont d6cod£es par une couche logicielle 45 "Interpretation 
commandes APDU" (APDU : "Application Protocol Data Unit" dont le role est d'orienter les 
commandes vers des modules de traitement qui peuvent etre : 

30 - un logiciel 46 de services de gestion de fichiers securises ; 

- un logiciel 47 de services cryptograph iques ; 

- un ou d'autres logiciels d'application 48 

Les modules de traitement 46, 47, 48 s'appuient sur des services de base offerts par le 
systeme d 'exploitation 49 de la carte k micro-circuit. 
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La figure 8A i I lustre I' architecture logicielie d'un systeme de mise en oeuvre de 
transactions s£curis6es faisant appel k des modules terminaux 1 dotes d'un microprocesseur 
s6curis6 3, conforrrtement au mode d'execution de ['invention de la figure 4A. 

Le bloc 51 d^signe les logiciels executes par le microprocesseur securis£ 3 du module 
5 terminal 1, le bloc 52 les logiciels executes par le microcontrdleur 2 ou PC 102 du module 
terminal 1, le bloc 53 les logiciels executes par le microprocesseur 30 d'une carte k micro- 
circuit 31, et le bloc 54 le logiciel principal d'application, ou Fournisseur de services 
applicatifs, implante dans le serveur Sap ou un ordinateur personnel PC. 

Le bloc 51 est similaire au bloc 43 de la figure 7, c'est-S-dire que le microprocesseur 
1 0 securise 3 a une architecture semblable k celle d'une carte k circuit integre. Le bloc 5 1 comprend: 

- un logiciel 60 de protocole de communication. 

- un systeme d f exploitation 61 

- un bloc 62 reprtsentant la partie du logiciel d'application implantee dans le module 
terminal 1, cette partie du logiciel d'application etant essentiellement constitute du logiciel 

15 filtre precite. Dtfferents modules logiciels de ce type correspondant k difterentes applications 
peuvent cohabiter dans le microprocesseur securise 3. 

- optionnellement, un logiciel 63 permettant d'assurer I'authentification du 
microcontrdleur standard 2 par le microprocesseur stcurist 3 et I'authentification du 
microprocesseur stcurist 3 du module terminal 1 par le microprocesseur 30 de la carte 31, 

20 - un logiciel 64 de gestion de fichier stcurist, 

- un logiciel 65 de services cryptograph iques. 

Le bloc 52 comprend : 

- un logiciel 70 de protocole de communication ; 

- un interpteteur de commandes 71 correspondant au logiciel 20 des figures 4B et 4C ; 
25 . - un logiciel d'authentification 72 permettant, en liaison avec le logiciel 63, I'authentification 

du microcontrdleur standard 2 par le microprocesseur securise 3 du module terminal 1 ; 

- des logiciels 73 de gestion des ressources internes du microcontrdleur 2 ; 

- des logiciels 74 de pilotage des interfaces avec I'utilisateur (gestionnaires 23 et 25 de 
I'ecran 4 et du clavier 5) ; 

30 - des logiciels 75 de pilotage des interfaces de communication 7, 8 et 9 (gestionnaires 22, 
24, 27) ; 

Enfin, le bloc 53 est similaire au bloc 43, mais ne comporte pas, dans I'exemple decrit 
par la figure 8A, de logiciel d'application ou filtre. II comprend : 

- un logiciel 80 de protocole de communication, 

35 - un logiciel 81 d' interpretation de commandes APDU, 
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- un logiciel 82 de services de gestion de fichier s^curise (contrdle du PIN par exemple), 

- un logiciel 83 de services cryptographiques (calculs cryptographiques symetriques k cl(§s 
secretes ou asymetriques, k cl<§s publiques et cl6s privies, etc..) permettant, entre autres, 
d'assurer, en liaison avec le logiciel 63, I "authentication du microprocesseur s£curis£ 3 du 

5 module terminal 1 par le microprocesseur 30 de la carte 31 , 

- le systeme d'exploitation 84 du microprocesseur 30 de la carte 31 . 

Le protocole de communication 60, 70, 80 permet de g£rer les ^changes de donnees entre: 

- le microprocesseur 30 de la carte 31 et le microcontrfileur standard 2 ou PC 102 du 
module terminal 1 ; 

10 - le microprocesseur securise 3 et le microcontraleur 2 du module terminal 1 ; 

- le microprocesseur securise 3 du module terminal 1 et le microprocesseur 30 de la carte 31 . 

La figure 8B est une vue similaire k la figure 8A illustrant Parchitecture logicielle du 
systeme dans le cas ou le module terminal 101 ne comporte pas le microprocesseur securise 
3, conformement au troisi^me mode d'execution du deuxteme mode de realisation de 

1 5 . I'invention de la figure 6. 

Sur la figure 8B, le bloc 152 designe les logiciels executes par le microcontrdleur 2 du 
module terminal 101, le bloc 153 les logiciels executes par le microprocesseur 130 d'une 
carte k micro-circuit programmable 131, et le bloc 154 le logiciel principal duplication 
implants dans le serveur Sap ou un ordinateur personnel PC. 

20 Le bloc 152 comprend les memes logiciels 70, 71 et 73 k 75 que le bloc 52 de la 

figure 8A, et un bloc 76 qui est un logiciel d'authentification du microcontrSleur standard 2 
du module terminal 101 vis-^-vis du microprocesseur 130 de la carte 131 . 

Le bloc 153 relatif au microprocesseur 130 de la carte 131 comprend les logiciels 62 
et 80 k 84 des blocs 51 et 53 de la figure 8A, ainsi qu'un logiciel 77 permettant, en liaison 

25 avec le logiciel. 76, d'assurer Pauthentification du microcontrSleur standard 2 du module 
terminal 101 vis-a-vis du microprocesseur 1 30 de la carte 131. 

A la difference d'un systeme conventionnel, dans le systeme de transaction securis^e 
selon I'invention, le logiciel filtre 62 qui traduit les requites de haut niveau de ('application 
en commandes elementaires executables par une carte k micro-circuit est implante dans 

30 Penvironnement utilisateur securise, c'est4-dire soit dans le module terminal 1 (pour les 

applications A1, A2 An des modes d'execution des figures 4A-4C et 5), soit dans une carte 

31, 131 k memoire semi-permanente utilisable avec le module terminal 1, 101 (pour les 
applications Ax du mode de realisation de la figure 4C et pour toutes les applications du 
mode de realisation de la figure 6). 
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Outre sa fonction de gestion d'une carte k micro-circuit, ce logiciel filtre 62 g£re les 
interactions avec Putilisateur, c'est-^-dire les sequences d'echange de donnees entre un 
utilisateur et le module terminal qui sont requises dans le cadre d'une application, ^changes 
qui ont lieu par Pintermediaire des moyens d'interface, k savoir Pecran 4 et le clavier 5. II est 
5 k noter que ['invention n'est pas limine k Putiiisation d'un ecran et d'un clavier comme 
interfaces avec Tutilisateur et que tout autre type d'interface, par exemple vocale, pr<§sentant 
Pergonomie requise, pourrait convenir, 

GrSce k Pimplantation s<§curisee du logiciel filtre 62 dans le microprocesseur securis£ 
3 ou 29 du module terminal 1 ou le microprocesseur 30, 130 de la carte k micro-circuit 31, 
10 131, la securite des transactions est assume. En effet, les cles et regies necessaires pour 
accSder k des fichiers de la carte k micro-circuit 31, 131 sont contenues dans le logiciel de 
traduction 62 et sont done inaccessibles a des tiers. 

Les fonctions remplies par le logiciel filtre 62 seront illustrees ci-apr£s en prenant 
Pexemple d'une application visant le commerce 6lectronique. L'application met en ceuvre 
1 5 les entites suivantes : 

• un acheteur 

• un commerfant, 

• une banque. 

Le commergant dispose d'un serveur de commerce 6lectronique Sap (serveur Web) 
20 accessible depuis le reseau Internet. Les acheteurs sont 6quipes de: 

• un ordinateur PC permettant d'acc6der au serveur Sap de commerce 
electronique, et grace auquel I'acheteur peut consulter un catalogue de marchandises. 

• une carte k circuit int6gr6 31 d6Iivr£e par la banque et dont le microprocesseur 
30 contient une cl6 privee, mais ne dispose pas de capacity cryptographiques permettant 

25 d'effectuer une signature, 

• un module terminal 1 selon le mode de realisation de : la figure 4A, dote d'un 
microcontrdleur standard 2, d'un microprocesseur s£curise 3 disposant de capacity 
cryptographiques permettant la signature d'un message, d'un clavier 5, d'un afficheur 4, d'une 
interface carte k circuit int£gr£ 6 et d'une interface s6rie 7 pour sa connexion k un ordinateur PC. 

30 Les principes de fonctionnement sont les suivants : la transaction est sign£e par le 

module terminal 1 k Paide d'une cl£ privee d&enue par la carte 31. Cette cl6 privee est 
protegee par un code porteur confidentiel (PIN) que Pacheteur doit saisir en milieu s6curise, 
done sur le terminal 1, et par une authentication prealable du terminal 1 par la carte 31 k 
Paide d'une cle secrete Kauth. De plus la cl£ privee est transmise de manure chiffree (par une 
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cl6 Kchif) de mantere k &ablir un canal de communication securise entre le microprocesseur 
30 de la carte k circuit integree 31 et le microprocesseur securise 3 du terminal 1 . 

La figure 9 illustre les ^changes entre les differentes entites : 

a. I'acheteurconstitue sa commande sur I'ordinateur PC, 
5 b. I'ordinateur PC 6labore la transaction a faire signer par I'acheteur (reference article, 

prix) et demande la signature de cette transaction au module terminal 1 , 

c. le module terminal v£rifie I'origine de la demande de signature puis sollicite la 
saisie du code PIN par affichage d'un message "saisie PIN" sur son afficheur 4, 

d. I'acheteur saisit son code porteur (code PIN) sur le clavier 5 du module terminal 1, 
10 e. le PIN est envoye par le module terminal 1 k la carte 31 pour verification. Cette 

verification 6tant positive, elle provoque la Iev6e d'une de deux conditions d'acc$s k la 
lecture de la cle privee, 

f. le module terminal 1 affiche la transaction sur son afficheur 4, 

g. I'acheteur donne son accord, par appui sur une touche "validation" du clavier 5 du 
15 module terminal 1, 

h. le module terminal 1 soumet une demande d'authentification externe k la carte 31. 
Cette authentification externe permet au microprocesseur securise 3 du module terminal 1 
de s'authentifier vis-a-vis du microprocesseur 30 de la carte 31 et de lever ainsi la deuxiSme 
protection d'acc^s £ la cl6 privee. Cette authentification se fait en mode challenge/r^ponse 

20 sur la base d'un secret, Kauth, partag£ par le module terminal 1 et la carte 31 , 

i. le module terminal 1 envoie une demande de lecture de cl6 privee k la carte 31, 

j. toutes les conditions d'acces etant remplies, la carte 31 accepte la demande de 
lecture, et renvoie la cle privee, chiffrSe par une cl6 secrete, Kchif, partagee par la carte 31 et 
le module terminal 1, 

25 k. le module terminal 1 dechiffre la cle privee, signe la transaction au moyen de la cle 

privSe, d&ruit la cl6 privee, se dSconnecte de la carte 31 et envoie e la transaction signee k 

I'ordinateur PC qui la transmet au serveur S. 

Cet exemple peut §tre transpose aisement k une transaction electronique effectuee 

sans ordinateur PC, le module terminal 1 se connectant directement k un serveur Sap par 
30 une liaison- modem (figure 3), I'acheteur entrant la commande (reference produit) sur le 

module terminal 1 . 

II est k noter que ['authentification du microprocesseur securise 3 par la carte peut 
aussi §tre effectu£ k travers la commande de lecture de cle privee en lui associant un code 
d'authentification MAC (Message Authentification Code) calcule au moyen d'une cle secrete. 
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Cet exemple montre que le logiciel filtre 62 permet de traduire une requete de haut 
niveau "demande de signature de transaction" en une multitude de requites 6lementaires 
adress^es aux differentes interfaces du module terminal 1, a savoir I'interface 6 avec la carte 
& circuit integre 31, i'interface afficheur 4, I'interface clavier 5, I'interface de connexion- a 
5 I'ordinateur PC ou au serveur Sap. 

Un te! logiciel filtre de traduction a un r£le d'ecran, de filtre entre le monde exterieur, 
c'est k dire les applications, et les p£ripheriques qu'il g£re. 

II ameliore la security offerte du fait que : 

1 . il impose un s£quencement aux ordres £l6mentaires envoy6s. Par exemple, dans le cas 
10 illustre ci-dessus, il impose que la transaction soit validSe par I'utilisateur avant d'etre signee. 

2. il dispose seul des param&res secrets permettant de gen£rer et d'authentifier ces ordres 
£l<§mentaires. Ainsi il dispose seul des cles d'authentification et de chiffrement permettant de 
lire et dechiffrer la cle privSe. 

Lorsque le logiciel filtre est execute dans le microprocesseur s6curis§ 3 du module 
1 5 terminal 1, ces proprietes permettent d'imposer une politique d'acc£s k la carte 31 , politique 
qui n'est pas toujours complement imposee par la carte elle-m6me, ou d'etendre les 
capacites d'une carte (capacity de signature d6legu6e au module terminal, utilisation dans un 
contexte non pr6vu lors de son d^ploiement initial). 

Les avantages offerts en terme de s^curite par PexScution du logiciel filtre dans le 
20 microprocesseur securise du module terminal ou dans celui de la carte k circuit integr£ ne 
sont possibles que parce que le logiciel s'ex6cute dans un environnement securise 
permettant d'assurer que : 

• les secrets contenus par le logiciel filtre ne sont pas accessibles du fait qu'ils sont 
m6moris6s au sein du microprocesseur securis6 3, 29, 30 ou 1 30, 
25 • la confidential ite et P integrity du logiciel filtre sont preserves, du fait que ce 

logiciel est memorise dans la microprocesseur securise 3, 29, 30 ou 1 30. 

Dans le cas ou le module terminal 1 est un produit d6die, disposant de ses propres 
interfaces, afficheur 4 et clavier 5, Pobjectif de security est atteint grSce au fait que le logiciel 
pilotant les ^changes de donnees avec I'utilisateur ne peut fitre modifte, dans la mesure ou il 
30 est stocks de mantere definitive dans la m^moire permanente 2c du microcontrfileur 2 ou de 
manure s£curis6e dans le microcontrdleur 29. L'utilisateur peut ainsi valider en toute 
confiance le contenu de sa transaction gr<ice k Pafficheur 4 et au clavier 5, rendant optionnel 
la n6cessit6 de verifier Pidentite de Papplication ou Porigine et Pint6grit£ des requ&tes. 

D'autres m^canismes peuvent encore am6liorer le niveau de security de la chalne de 
35 confiance entre le microprocesseur securis6 de la carte k circuit int£gr£, I'eventuel 



WO 99/62037 PCT/FR99/01202 

32 

microprocesseur securise du module terminal, le microcontr6leur standard ou !e PC du 
module terminal et I'uttlisateur. Ces mecanismes sont les suivants : 

A) telechargement securise du logiciel filtre ; 

B) authentification du microcontrSleur standard par le microprocesseur securise ou, ce 
5 qui est equivalent mais mieux adapte dans le cas d'un mode d'execution du terminal autour 

d'un PC, authentification du module logiciel interpreter I (20) par le logiciel filtre F (62), 
et/ou etablissement d'un canal de communication securisee entre ces deux microprocesseurs 
ou les logiciels I et F, 

C) protection d'un secret par le microcontr&leur standard , 

10 D) authentification mutuelle et etablissement d'un canal de communication securise 

entre le microprocesseur securise de la carte k circuit integre et le microprocesseur securise 
du module terminal, 

E) authentification du module terminal, et eventuellement du couple module terminal- 
carte, 

1 5 F) authentification de la carte k micro-circuit par le module terminal. 

A) Telechargement securise du logiciel filtre 

L'organigramme de la figure 10 illustre le processus de telechargement d'un 
programme duplication (logiciel filtre) dans le microprocesseur securise 3 ou 29 du 
module 1 ou le microprocesseur securise 30, 130, d'une carte 31, 131 presente dans le 

20 lecteur 6. Ce telechargement peut etre effectue k partir d'un serveur Sap via, par exemple, 
I'ordinateur personnel PC et ('interface 7 de liaison exteme ou ('interface 8 de liaison 
infrarouge, ou directement au moyen d'une liaison teiephonique grace k I'interface 9 de 
liaison par DJMF. Le telechargement peut egalement etre effectue dans le microprocesseur 
securise 3 ou 29 (si le module terminal en est equipe) k partir d'une carte k micro-circuit 

25 introduite dans le lecteur 6. 

A I'etape 32, la zone de la memoire 3d allouee au programme d'application a recevoir 
est vide et le microprocesseur 3 est en attente du chargement du programme d'application k 
la suite d'une requSte de chargement. 

L'etape suivante 33 correspond k une procedure d'authentification par le 

30 microprocesseur 3 de I'entite appelee k telecharger le programme d'application (Emetteur). 
Cette procedure d'authentification peut faire appel, par exemple, k des mecanismes de 
chiffrement bien connus des specialistes de la technique, par exemple des mecanismes 
symetriques k des secretes partagees ou des mecanismes asymetriques k cle privee et cie 
publique. 



WO 99/62037 PCT/FR99/01202 

33 

L'etape 34 est un test visant k determiner si ia procedure d'authentification a reussi : 
dans la negative, le message M acc£s refuse" est affiche sur Pecran 4 (etape 42) et le 
programme retourne k Petape 32; dans Paffirmative, le processus de chargement du 
programme duplication commence k Petape 35. 
5 L'etape 36 correspond au stockage dans la memoire EEPROM 3d des trames.de 

donnees transmises par Pentite assurant le telechargement. 

L'etape 37 est un test pour determiner si le telechargement est acheve : dans la negative, 
le programme de telechargement revient k Petape 36 et le telechargement se poursuit ; dans 
Paffirmative, il est precede k Petape 38 k une verification de Pintegrite des donnees re?ues par 

10 le microprocesseur 3. A cet effet, un code d'authentification de message (MAC) peut etre 
associe au programme telecharg^ pour permettre de verifier non seulement son integrite, mais 
egaiement son origine. Le MAC peut etre produit en utilisant un mkanisme de cryptographie 
sym&rique (DES en mode chaine CBC). La verification de Porigine et de Pintegrite peut aussi 
fitre realisee k Paide d'un mecanisme de cryptographie asymetrique : un condense du logicie! 

15 tetecharge est signe par I'emetteur k I'aide de sa cle privee ; le microprocesseur securise 3 
verifie ensuite la signature k I'aide de la cle publique de I'emetteur. 

II est k noter que dans ce dernier exemple, la cle publique par principe ne necessite 
pas de rester confidential le. Cependant la s^curite apportee par le microprocesseur assure 
Pintegrite du logiciel, empSchant un fraudeur de modifier le logiciel pour supprimer la 

20 verification de signature ou simplement de substituer k la cle publique initialement prevue 
une cle publique pour laquelle il connaitrait la cle privee associee. 

Si d'apr^s le test 39, il s'av^re que les donnees regues sont correctes, un drapeau 
indiquant que le programme duplication re?u est valide est elabore k Petape 40. Dans le 
cas contraire, le programme de telechargement revient k Petape 32 de depart. 

25 Ce processus de chargement du logiciel duplication, done du logiciel filtre, dans la 

memoire reprogrammable securis£e (3d, 30a, 130a suivant le mode de realisation), 
comporte des mecanismes permettant de confirmer Porigine et Pintegrite des donnees revues 
de I'emetteur du logiciel. Ceci permet d'interdire le teiechargement par un fraudeur d'un 
logiciel filtre qui serait susceptible de mettre en oeuvre des transactions dans le module 

30 terminal 1, 101 k Pinsu de Putilisateur. 

B) Authentification du module logiciel interpreter I, 20, 71 par le logiciel filtre F, 62 
ou, ce qui est equivalent dans le mode d'execution correspondant, authentification du 
microcontrdleur standard 2 par le microprocesseur securise, et/ou etablissement d'un 
canal de communication securise entre ces deux logiciels ou ces deux microprocesseurs. 
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Pour qu'un utilisateur puisse avoir une totale confiance dans le module terminal au 
moyen duquel il effectue des transactions, il est n^cessaire : 

- d'authentifier les donnees transmises du logiciel interpr&eur 20, 71 au 
microprocesseur securis£ 3, 30 ou 130 executant le logiciel filtre ; 
5 - d'assurer que les donnees transmises par le logiciel filtre pour gtre affichees par 

I'intermediairedu logiciel interpr&eur du module terminal 1, 101 possede par I' utilisateur ne 
peuvent I'&tre que par celui-ci. 

Lorsque les moyens de pilotage des ^changes de donnees avec I'utilisateur, c'est k dire 
le logiciel interpreter 20, 71, sont implants de mantere fixe et non modifiable dans le 
10 module terminal 1,101, comme par exemple dans la mSmoire ROM 2c du microcontroleur 
standard 2, I'authentification du module logiciel est Squivalente a I'authentification du 
rnicrocontrdleur. 

De mgme, lorsque le logiciel filtre est implants de manure k ne pas pouvoir etre 
modify par une personne non autorisSe, dans des moyens de traitement securis«§s tels que le 
15 microprocesseur s6curis6 3, la carte k circuit int6gr£ ou bien le serveur s<§curise Ssec, une 
authentification effectu<§e par ces moyens securises est equivalente k une authentification . 
effectue par le logiciel filtre lui-mfrme. 

Dans la description qui suit, nous d£crirons les mecanismes d'authentification des 
moyens logiciels de pilotage des interfaces ou logiciel interpreter 20, 71 par le logiciel filtre. 
20 Differentes solutions permettent de remplir ces conditions. 

Une premiere solution consiste k chiffrer toutes les donnees £changees entre le le 
logiciel interpreter 20, 71 et le logiciel filtre. 

Une deuxteme solution consiste k faire procSder k Pauthentification du logiciel 
interpreter 20, 71 par le le logiciel filtre et/ou k etablir un canal de communication securise 
25 entre ces deux logiciels. 

Ces deux solutions impliquent n^cessairement qu'au moins un param&re' secret connu 
du logiciel filtre F, 62, soit stocke dans le logiciel interpreter 20, 71 . 

Selon la deuxieme solution, le logiciel filtre F, 62 authentifie le logiciel interpreter 20, 
71, selon un processus conventionnel d'authentification, sur la base d'une information 
30 transmise par le logiciel interpreter 20, 71, et combinee avec le param&re secret. Au 
niveau du logiciel interpreter 20, 71, cette procedure d'authentification est mise en ceuvre 
par le logiciel 72 (figure 8A) ou le logiciel 76 (figure 8B), suivant la forme de realisation du 
module terminal. 
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Ce mecanisme d'authentification peut egalement s'appliquer aux messages echanges 
entre les deux logicielspour construire des codes d'authentification des messages permettant 
de garantir Torigine et I'integrite de chaque message transmis. 

Dans !e cas du mode d'execution decrit k la Figure 4A, cette solution requiert 
5 cependant que, de preference, une protection physique de la liaison entre les deux 
microprocesseurs soit assume pour interdire ci un fraudeur de lire les donnees echangees, et 
en particulier le code d'identification personnel (PIN) de la carte que I'utilisateur peut Stre 
amene k introduire via le clavier 5 pour la mise en oeuvre des transactions. 

C) Protection d'un parametre secret par le microcontroleur standard 2 

1 0 La description precedente montre la necessite de stacker au moins un parametre secret 

dans le logiciel interpreter. Le mode d'execution du terminal k partir d'un PC, dans lequel 
le logiciel interpreter est execute sur le PC lui-meme, offre done de par la securite limitee 
du PC un degre de securite limite bien que suffisant pour emp^cher un virus de se substituer 
au logiciel interpreter. Un degn§ de securite superieur est obtenu en implantant le logiciel 

15 interpr^teur dans la ROM 2c du microcontroleur standard 2. Pour ameiiorer la security le 
parametre secret du microcontr&leur 2 pourra etre stocks dans la memoire temporaire, et 
cela k la fabrication du produit ou, eventuellement, lors de Pinsertion du microprocesseur 
securise 3 s'il est amovible, ou d'une carte k circuit integre. Cette operation a pour but 
d'etablir une confiance entre les deux microprocesseurs. Toute precaution utile doit etre 

20 prise lors de cette operation pour s'assurer de I'authenticite du microcontrdleur 2 (operation 
effectuee en usine, operation protegee par des des dites de transport elles-memes stockees 
dans la memoire temporaire du microcontrdleur 2 en usine, et dont la connaissance 
conditionne 1'operation d'initialisation dudit parametre secret). En outre des mecanismes 
conventionnels de detection d'intrusion (contacts...) seront mis en place, pour provoquer 

25 Peffacement de la memoire temporaire en cas d'intrusion (coupure alimentation...). 

D) Authentification mutuelle et etablissement d'un canal de communication securise 
entre le microprocesseur de la carte h circuit int£gr6 et le microprocesseur securise du 
module terminal 

Cette authentification mutuelle et I'etablissement du canal de communication 
30 s§curis£e sont realises par la mise en oeuvre de mecanismes identiques k ceux utilises entre 
le microcontrdleur standard 2 et le microprocesseur securise executant le logiciel filtre 
comme decrit au point B) ci-dessus. 

E) Authentification du module terminal 

II est important de se premunir vis-^-vis de toute attaque contre ('ensemble clavier 5, 
35 afficheur 4, microprocesseur securise 3, visant par exemple k effectuer des contrefafons de 
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module terminal , k substituer un module terminal par un module terminal contrefait dans le 
but de recuptrer des informations saisies par I'utilisateur (espionnage clavier), d'acceder aux 
secrets d'une carte £ circuit integr£, d'effectuer des fausses signatures. 

Pour cela, il pourra etre ajoutg un m&ranisme permettant k I'utilisateur d'authentifier 
5 son terminal. 

Cet objectif est atteint grace k un processus de personnalisation automatique. 
Authentication du module terminal seul 

La personnalisation peut consister en le calcul d'un mot de passe facile k se rappeler 
g6n£re et afficht par le terminal en fonction des param£tres secrets contenus par le ou les 

10 microprocesseurs du terminal, lorsque I'utilisateur introduit un PIN. Si le terminal comporte 
par exemple deux microprocesseurs, le mot de passe est stocke dans le microprocesseur 
stcurise, chiffre par le PIN et une cle secrete X, puis transmis au microcontr6leur 2 pour 
d£chiffrement avec la cl<§ X stockee 6galement dans le microcontrdleur 2 et le PIN introduit 
par I'utilisateur, Ce mecanisme vise a se premunir contre la substitution de I'un des deux 

15 microprocesseurs. 

Le m£me principe peut Stre appliqut k un couple carte/terminal k chaque fois qu'une 
carte £ micro-circuit est utiliste avec le module terminal. La personnalisation peut consister 
par exemple en le calcul, au moyen du logiciel de traduction, d'un mot de passe base sur 
une information secrete contenue dans le microprocesseur securis£ de la carte et d'une ou 

20 plusieurs informations secretes contenues dans module terminal. Le mgme principe que 
celui decrit ci-dessus peut Stre utilise pour calculer le mot de passe. Ce mot de passe, g^nere 
lors de la premiere utilisation du module terminal en conjonction avec la carte et connu de 
I'utilisateur, est affich6 sur l'6cran 4 lors des utilisations subsequentes du module terminal 
avec la carte. L'utilisateur peut ainsi le verifier et avoir ainsi Passurance que le terminal en sa 

25 possession, constitu6 du module terminal couple k la carte, est bien authentique. 
F) Authentif ication de la carte k micro-circuit par le module terminal 
Pour accroitre encore la security du systeme de transaction suivant 1'invention, un 
processus conventionnel d'authentification peut fitre mis en oeuvre afin d'assurer 
I'authentification par le module terminal 1, 101 de la carte a micro-circuit utilisee. Un tel 

30 processus d'authentification permet notamment d'eviter que le numero d'identification 
personnel (PIN) de I'utilisateur, que celui-ci introduit dans le module 1, 101 par le clavier 5 
pour ex^cuter une transaction s6curis6e, soit capture par une carte falsifiee qui aurait et6 
substitute par un fraudeur k la carte authentique de I'utilisateur puis que ce fraudeur 
r6cup6rerait pour lire le PIN sur la carte falsifiee. L'authentif ication peut, par exemple, gtre 

35 effectute par un mecanisme classique de type d6fi / r£ponse au moyen d'un secret partage 
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entre la carte et le module terminal en utilisant une cryptographie synrtetrique ou bien, 
comme cela a deja ete decrit pr£c£demment, au moyen d'une cle privee stockee par la carte 
permettant le chiffrement du defi ou challenge a I'aide d'un algorithme asyrrtetrique, le 
module terminal vSrifiant la reponse a I'aide de sa c\€ publique. 
5 L'architecture du systeme de transaction ainsi que les mecanismes de s&rurisation 

d£crits ci-dessus conferent une tr^s grande securite aux transactions effectu^es au moyen du 
module terminal 1, 101. 

Ce module terminal permet : 

- grace au clavier 5, a I'Scran 4 et a la protection des donnees echangees avec 
10 I'utilisateur, d'&endre la nature des services teellement securis£s que peut foumir une carte a 
micro-circuit ; 

• d'utiliser la carte dans le contexte d'un environnement non s6curis£ (ordinateur 
personnel PC susceptible d'etre affects par des virus ou programmes pirates), en I'isolant 
hermetiquement de cet environnement grace a une architecture logicielle et/ou materielle 
15 qui contrdle strictement facets a la carte, e'est a dire qui contrdle les commandes envoyees 
aux fonctions cryptographiques contenues dans la carte. 

Le module terminal peut rev&ir differentes formes telles que : 

• un lecteur de carte k circuit integte, connectable a un ordinateur via differentes 
interfaces (PCMCIA...) ou non {connexion a un serveur via modem uniquement) ; 

20 • un ordinateur (PC) dont les interfaces utilisateur sont constitutes par I'tcran et le 

clavier du PC, et qui comporte un lecteur de carte a circuit integte. Ce PC inclura des 
moyens logiciels et / ou materiels (tels qu'un second microprocesseur securise, le 
microcontrdleur standard 6tant constituS par le PC) pour assurer I'integrite et la 
confidentiality du logiciel filtre. Par ordinateur on entend un ordinateur de type PC, mais 

25 6galement un PDA (* Personal Digital Assistant * ou Assistant Nunrterique Personnel) ; 

• un clavier, 6ventuellement muni d'un 6cran d'affichage LCD, dans iequel est 
integte un microprocesseur s£curis6 et une interface carte a circuit integte ; 

• un telephone muni tventuellement d'un afficheur, dans Iequel est integte un 
microprocesseur s6curis6 et une interface carte a circuit integr£ ; 

30 • un dtcodeur (set-top box) de teseau cable de TV integrant un lecteur ce carte a 

circuit integte connects a un poste de television, le poste de television, un clavier ou 
eventuellement la tetecommande associe au decodeur ou a la television servant de 
moyens d'interface avec I'utilisateur ; 

• plus generalement tout equipement s£curisable par ('integration d'un 
35 microprocesseur securise dans Iequel pourra etre installee une application dite sensible, 
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ou par ('integration d'une interface carte a circuit integre" permettant le pilotage dudit 
£quipement par une application deportee dans une carte a circuit integre\ 

L'ensemble de la description prec6dente d£crit un terminal destine" a §tre utilise" 
avec une carte a circuit integr<§ ou "smart card". La carte a laquelle il est fait reference est 
5 en fait un outil permettant la mise en oeuvre de fonctions cryptograph iques et 
personnalise par rapport a un utilisateur au moyen d'au moins un secret. II est evident- 
que I'objet de I'invention ne se limite pas a un outil de forme donnee tel que celui de la 
carte a circuit integre\ L'invention couvre aussi la mise en oeuvre de dispositifs personnels 
de security pouvant offrir des fonctions equivalentes a celle d'une carte a circuit integre\ 
10 mais pr&entes sous une forme diffgrente, tels que les produits ' i Button " Java Ring " 
ou jeton {" token "). 
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REVINDICATIONS 

1. Terminal pour la mise en ceuvre, par un utilisateur, de transactions Slectroniques 
s<§curisees en liaison avec au moins une application implantee sur une unite Slectronique, 
ledit terminal comprenant : 

- un module terminal comportant au moins : 

5 * des premiers moyens d'interface avec ladite application pour en recevoir des 

requStes relatives auxdites transactions, 

* des deuxtemes moyens d'interface avec ledit utilisateur, 

* des troistemes moyens d'interface avec un dispositif personnel de s^curite, 

* des premiers moyens de traitement de donnees comprenant au moins des premiers 
10 moyens logiciels de pilotage desdits moyens d'interface, et 

- un dispositif personnel de securite comportant au moins des deuxtemes moyens de 
traitement de donnees securis^s comprenant au moins des deuxiemes moyens logiciels 
d'ex&rution de commandes 6l6mentaires et des moyens d'execution de calculs cryptograph iques, 

caracterise en ce que : 

15 - ledit terminal (1, 31 ; 101, 131) est adapte pour recevoir lesdites requites de ladite 

application (Fap) implantee sur la dite unite Slectronique (Sap ; PC) sous la forme de requ&es 
de haut niveau independantes dudit dispositif personnel de securite, 

- fun au moins dudit module terminal (1; 101) et dudit dispositif personnel de securite 
comprend: 

20 * au moins une rrtemoire reprogrammable (3d ; 30a ; 102b ; 130a ; Ssec) de 

stockage d'au moins un logiciel filtre (F, 62), traduisant lesdites requites de haut niveau en au 
moins Tune de : 

(i) au moins une commande elemental re ou une sequence de commandes 
6!6mentaires ex£cutables par lesdits deuxtemes moyens logiciels (80-84) desdits deuxiemes 

25 moyens de traitement de donnees (30 ; 1 30), ou 

(ii) au moins une sequence d'&rhange de donnees entre ledit module terminal (1 ; 101) 
et ledit utilisateur via lesdits seconds moyens d'interface (4, 5), ex&rutables par lesdits premiers 
moyens logiciels (I, 20, 71) desdits premiers moyens de traitement de donnees (2 ; 29 ; 102), 

* des moyens de protection dudit logiciel filtre (F, 62), pour emp£cher toute 
30 lecture et/ou modification dudit logiciel filtre par une entity non autorisee, et 

- I'un au moins desdits premiers et deuxiemes moyens de traitement de donnees (3 ; 29 
, 30 ; 102 ; 130 ; Ssec) comprend un dispositif de traitement de donnees pour l'ex£cution 
dudit logiciel filtre (F, 62). 
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2. Terminal selon la revendication 1, caracterise en ce que ledit dispositif d'execution 
du logiciel filtre comprend des premiers moyens d'identification et /ou d'authentification de 
ladite application (Fap) implantee dans ladite unite electronique (Sap; PC) ou de I'origine 
desdites requites emises par ladite application. 
5 3. Terminal selon la revendi cations 2, caracterise en. ce que ledit dispositif de 

traitement de donnees pour I'execution dudit logiciel filtre (F, 62) comprend des moyens de 
verification de Tintegrite des donnees reg ues de ladite application (Fap). 

4. Terminal selon Tune quelconque des revendications 1 k 3, caracterise en ce que ledit 
dispositif de traitement de donnees pour I'execution dudit logiciel filtre (F, 62) comprend des 

10 moyens centralises (Ssec) de contr6le des conditions d'utilisation des services du dispositif 
personnel de security (31) en fonction de ladite application (Fap) et/ou de I'utilisateur. 

5. Terminal selon Tune quelconque des revendications 1 k 4, caracterise en ce que ledit 
dispositif de traitement de donnees pour ('execution dudit logiciel filtre (F, 62) comprend : 

-des moyens pour commander le chargement securise dudit logiciel filtre dans ladite 
15 nrtemoire programmable, via Tun desdits premiers ou troistemes moyens d'interface, d partir 
d'une entite exterieure audit module, et 

- des premiers moyens de contrdle d'accfcs pour n'autoriser ledit chargement dudit 
logiciel filtre qu'en reponse £ au moins une condition predefinie. 

6. Terminal selon Tune quelconque des revendications 1 & 5, caracterise en ce qu'il 
20 comprend des deuxtemes moyens d'authentification desdits premiers moyens de traitement de 

donnees (2 ; 3 ; 29 ; Ssec) par lesdits deuxtemes moyens de traitement de donnees (30 ; 130). 

7. Terminal selon Tune quelconque des revendications 1 & 6, caracterise en ce qu'il 
comprend des troistemes moyens d'authentification desdits deuxtemes moyens de traitement 
de donnees (30 ; 1 30) par lesdits premiers moyens de traitement de donnees (3 ; 29). 

25 8. Terminal selon I'une quelconque des revendications 6 et 7, caracterise en ce qu'il 

comprend un premier canal de communication (6) entre lesdits premiers (2 ; 3 ; 29) et 
deuxtemes (30 ; 130) moyens de traitement de donnees et des premiers moyens de 
s£curisation dudit premier canal de communication. 

9. Terminal selon Tune quelconque des revendications 1 & 8, caracterise en ce qu'il 
30 comprend des quatri£mes moyens d'authentification dudit module terminal (1 ; 101) par 

ledit utilisateur, independamment dudit dispositif personnel de securite (31 ; 131). 

10. Terminal selon la revendication 9, caracterise en ce que lesdits quatriemes moyens 
d'authentification comprennent des moyens de calcul, par lesdits premiers moyens de 
traitement de donnees (2 ; 3 ; 29), et de presentation audit utilisateur, via lesdits deuxiemes 

35 moyens d'interface (4), d'un mot de passe connu dudit utilisateur et calcuie sur la base d'au 
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moins un premier param&re secret stocke dans lesdits premiers moyens de traitement de 
donn<§es (2 ; 3 ; 29). 

1 1 . Terminal selon I'une quelconque des revendications 1^10, caract£rise en ce qu'il 
comprend des cinquifemes moyens d'authentification conjointe dudit module terminal (1 ; 

5 1 01 )et dudit dispositif personnel de security (31 ; 131) par ledit utilisateur. 

12. Terminal selon la revendication 11, caract6ris6 en ce que lesdits cinqutemes 
moyens d'authentification comprennent des moyens de calcul, par ledit dispositif 
d'ex£cution dudit logiciel filtre (3 ; 29 ; 31 ; 131), et de presentation audit utilisateur, via 
lesdits deuxi£mes moyens d'interface (4), d'un mot de passe connu dudit utilisateur et 

10 calculi sur la base d'au moins un deuxteme et un troisteme parametres secrets stockes en 
memoire respectivement dans lesdits premiers (2 ; 3 ; 29) et deuxi£mes (30 ; 1 30) moyens de 
traitement de donnees. 

13. Terminal selon Tune quelconque des revendications 1^12, caracterise en ce que 
ledit module terminal (1) comporte ladite memoire programmable (3d) pour le chargement 

15 et le stockage dudit logiciel filtre (F, 62). 

14. Terminal selon la revendication 13, caract£ris£ en ce que ledit logiciel filtre (F, 62) 
g6n6re des premieres commandes pour la mise en ceuvre de ladite sequence d'6changes de 
donnees entre ledit module terminal (1) et ledit utilisateur, et en ce que lesdits premiers 
moyens de traitement de donnees comprennent un premier microprocesseur (2 ; 102) de 

20 pilotage desdits moyens d'interface (4-9) programme grace auxdits premiers moyens logiciels 
(20, 71) de pilotage desdits moyens d'interface pour executer lesdites premieres commandes 
gen£rees par ledit logiciel filtre (F, 62), et un deuxi&me microprocesseur securise (3) du type 
pour carte £ circuit int6gr<§ dispose dans ledit module terminal et comportant ladite memoire 
programmable (3d), ledit second microprocesseur. (3) executant ledit logiciel filtre (F, 62) 

25 pour le pilotage de ladite sequence d'echanges de donnees au moyen desdites premieres 
commandes transmises audit premier microprocesseur (2) et pour ^application de ladite 
commande £tementaire ou sequence de commandes 6l£mentaires auxdits deuxtemes 
moyens de traitement de donnees. 

15. Terminal selon la revendication 14, caracterise en ce que lesdits premiers moyens 
.30 logiciels (20, 71) de pilotage des moyens d'interface comportent au moins un quatrteme 

param&re secret, ledit deuxi£me microprocesseur (3) &ant commands par ledit logiciel filtre 
(F, 62) pour authentifier lesdits premiers moyens logiciels (20, 71) de pilotage des moyens 
d'interface sur la base d'une information transmise par ledit premier microprocesseur (2) et 
cornbin6e au moins avec ledit quatri&me param^tre secret. 
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16. Terminal selon la revendication 15, caract6ris£ en ce qu'il comprend un deuxi£me 
canal de communication (12) entre lesdits premiers moyens logiciels (20, 71) de pilotage des 
moyens d'interface et ledit deuxi£me microprocesseur (3) et des deuxi£mes moyens de 
securisation dudit deuxi£me canal de communication. 
5 17. Terminal selon la revendication 16, caracterise en ce que lesdits deuxtemes 

moyens de securisation comprennent des moyens de chiffrement et dechiffrement, par 
lesdits premiers moyens logiciels (20, 71) et par ledit deuxiSme microprocesseur (3), des 
donnees transmises sur ledit deuxi^me canal de communication (12), sur la base d'au moins 
un cinqui£me param6tre secret memorise dans lesdits premiers et deuxtemes moyens de 
10 traitement de donnees. 

18. Terminal selon Pune quelconque des revendications 16 et 17, caracterise en ce 
que lesdits deuxtemes moyens de securisation comprennent des premiers moyens physiques 
de protection dudit deuxi£me canal de communication (12) contre les intrusions. 

19. Terminal selon Tune quelconque des revendications 15 a 18, caracterise en ce 
15 que ledit premier microprocesseur (2) comporte une memoire temporaire (2b) pour le 

stockage dudit param&tre secret et des deuxtemes moyens physiques de protection de ladite 
memoire temporaire (2b) contre les intrusions. 

20. Terminal selon I'une quelconque des revendications 14 ^ 19, caracterise en ce 
que ledit deuxi£me microprocesseur (2) est un rnicrocontraleur. 

20 21 . Terminal selon la revendication 1 3, caracterise en ce que ledit logiciel filtre g£n6re 

des premieres commandes pour la mise en oeuvre de ladite sequence d'echanges de 
donnees entre ledit module terminal et ledit utilisateur et lesdits premiers moyens de 
traitement de donnees comprennent ledit dispositif d 'execution du logiciel filtre et sont 
constitues par un microprocesseur securise (29) adapte pour : 
25 * exporter ledit logiciel filtre (F, 62) de traduction et de conversion desdites 

requetes de haut niveau en au moins une sequence d'echanges de donnees entre le 
module terminal et I'utilisateur et/ou en au moins une commande elementaire ou une 
sequence de commandes £lementaires ex£cutables par lesdits deuxtemes moyens 
logiciels desdits deuxternes moyens de traitement de donnees (31), 
30 * piloter lesdits moyens d'interface (4-9) grace auxdites premieres commandes 

generSes par ledit logiciel filtre, pour la mise en ceuvre de ladite sequence d'echanges 
entre ledit module terminal (1) et ledit utilisateur. 
22. Terminal selon la revendication 21, caracterise en ce que ledit microprocesseur 
(29) comporte ladite memoire programmable. 
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23. Terminal selon la revendication 21, caracteris£ en ce que ladite memoire 
programmable est exteme audit microprocesseur (29). 

24. Terminal selon la revendication 23, caracteris6 en ce que ledit logiciel filtre (F, 62) 
est stocke sous forme chiffree dans ladite memoire programmable et en ce que ledit 

5 microprocesseur (29) comprend des moyens pour lire, d&rhiffrer et executer ledit logiciel filtre. 

25. Terminal selon I'une quelconque des revendications 14 k 24, caracteris<§ en ce 
que lesdits deuxtemes moyens de traitement de donnees dudit dispositif personnel de 
securite (31) comprennent un deuxteme dispositif de traitement de donnees (30) pour 
I'ex^cution securisee d'un logiciel filtre et une memoire programmable (30a) pour le 

10 chargement et le stockage dudit logiciel filtre (62), lesdits premiers moyens logiciels desdits 
premiers moyens de traitement de donnees 6tant adapts pour recevoir lesdites cpmmandes 
pour la mise en oeuvre de ladite sequence d'6change de donnees indifferemment de Tun ou 
I'autre desdits dispositifs (3 ; 29 ; 31) d'execution de logiciel filtre implants dans ledit 
module et ledit dispositif personnel de securite respectivement. 

1 5 26. Terminal selon I'une quelconque des revendications 1 3 k 25, caracterise en ce que : 

- ledit logiciel filtre (F, 62) comprend au moins un param£tre secret, 

- lesdits deuxtemes moyens de traitement (30) de donnSes comprennent des seconds 
moyens de contrOle d'accSs conditionnels pour n'autoriser Texecution desdits calculs 
cryptograph iques, en reponse a des commandes elementaires generees par ledit logiciel filtre 

20 (F, 62), que si au moins une seconde condition pr&tefinie, fonctioh dudit param£tre secret est 
remplie. 

27. Terminal selon i'une quelconque des revendications 1 & 12, caracterise en ce que 
ledit dispositif personnel de securite (131) comporte ladite memoire programmable (130a) 
pour le chargement et le stockage dudit logiciel filtre (F, 62). 

25 28. Terminal selon la revendication 27, caracterise en ce que ledit logiciel filtre (F, 62) 

gen£re des premieres commandes pour la mise en oeuvre de ladite sequence d'echanges de 
donnees entre ledit module terminal (1) et ledit utilisateur et ce que lesdits premiers moyens 
de traitement de donnees comprennent un premier microprocesseur (2 ; 102) de pilotage 
desdits moyens d'interface (4-9), programme grace auxdits premiers moyens logiciels (20, 

30 71), pour executer lesdites premieres commandes, g6n£r6es par ledit logiciel filtre (F,62), et 
lesdits deuxtemes moyens de traitement de donnees comprennent un deuxteme 
microprocesseur s^curise (130) du type pour carte a circuit integre dispose dans ledit 
dispositif personnel de securite (131) et comportant ladite nrtemoire programmable (130a), 
ledit second microprocesseur (130) executant (i) ledit logiciel filtre (F, 62) pour le pilotage de 

35 ladite sequence d'6changes de donn6es au moyen desdites premieres commandes 
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transmises audit premier microprocesseur (2 ; 102), ainsi que (ii) lesdites commandes 
6lementaires. 

29. Terminal selon les revendications 6 et 28, caracterise en ce que lesdits premiers 
moyens logicieis (20, 71) de pilotage desdits moyens d'interface component au moins un 

5 param&re secret et ledit second microprocesseur (130) dudit dispositif personnel de securite 
(131) est command** par ledit logiciel filtre (62) pour authentifier ledit premier 
microprocesseur (2) sur la base d'une information transmise par ledit premier 
microprocesseur (2) et combinee au moins avec ledit param&re secret. 

30. Terminal selon Tune quelconque des revendications 28 et 29, caracterisS en ce 
10 que ledit deuxieme microprocesseur (130) dudit dispositif personnel de securite (131) est 

adapts pour commander le chargement dudit logiciel filtre (F, 62) dans ladite memoire 
programmable (130a) via lesdits premiers moyens d'interface (7-9) et lesdits troisiSmes 
moyens (6) d'interface avec ledit dispositif personnel de securite (131). 

31. Terminal selon Tune quelconque des revendications 13 £ 30, caracterisS en ce 
15 que ledit module terminal (1 ; 101) est constitue par un lecteur de carte £ circuit integre et 

ledit dispositif personnel de securite est une carte & circuit integre (31 ; 131). 

32. Terminal selon la revendication 13, caracterise en ce que ledit module terminal (1) 
comprend un ordinateur personnel (102) et en ce que ladite nrtemoire reprogrammable est 
constitute par le disque dur (102b) dudit ordinateur. 

20 33. Terminal selon la revendication 32 et I'une quelconque des revendications 14 a 

17, caracterise en ce que ledit premier microprocesseur est constitue par le microprocesseur 
(102c) dudit ordinateur personnel (102), ledit ordinateur personnel (102) etant en outre 
interface audit microprocesseur sScurisS (3). 

34. Terminal selon la revendication 32, caracterise en ce que ledit logiciel filtre (F) 
25 comprend un premier module de chargement/dSchiffrement (Fed) et un deuxteme module 

chiffte (Fchi) pour ladite traduction des requites de haut niveau, ledit premier module (Fed) 
commandant le chargement dudit deuxteme module (Fchi) en memoire RAM dudit ordinateur 
(1 02) et son dechiffrement pour I'exScution dudit logiciel filtre par ledit ordinateur. 

35. Terminal selon la revendication 32, caracterisS en ce que ledit logiciel filtre (F) 
30 comprend au moins un premier module (F-PQ implante sur ledit ordinateur personnel (1 02) et au 

moins un deuxi&me module (F-5E) implante sur un serveur de security (Ssec), ledit ordinateur 
personnel (102) et ledit serveur de securite (Ssec) etant connectes par un canal de communication 
sScurise (CS) permettant un Schange de donnSes protegS entre lesdits modules. 

36. Terminal selon Tune quelconque des revendications 32 a 35, caracterise en ce 
35 que ledit dispositif personnel de sScurite (31) est une carte k circuit integre. 
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37. Systeme pour la mise en oeuvre de transactions s6curis6e, caracterise en ce qu'il 
comprend au moins un terminal (1, 31 ; 101, 131) selon I'une quelconque des 
revendications 1 k 36, et au moins une unite Electron ique (Sap ; PC) comportant des moyens 
pour transmettre lesdites requfitesde haut niveau audit terminal (1/31 ; 101, 131). 
5 38. Systeme selon la revendication 37, caracterise en ce qu'il comprend une plurality 

de terminaux (1, 31 ; 101, 131), au moins un serveur (S) constituant ladite unite 
Slectronique, et des moyens (CR) de transmission de donn^es nunrteriques entre ledit serveur 
(S) et lesdits terminaux. 
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The present invention concerns a terminal and a system for performing secure 
electronic transactions. 

Public digital data transmission networks, such as the Internet, are expanding at a 
considerable rate. However, the performing of secure electronic transfers on this type of network 
5 is currently being hampered, among other things, by the lack of security mechanisms associated 
with such transactions, reflected in a lack of confidence on the part of network users and 
operators. 

In the context of this application: 

-an electronic transaction designates an exchange of information via a public digital 
10 data transmission or telecommunication network, either between two or more users or between a 
user and a service provider, 

- a function is a process carried out in order to render a service to a user, 

- an application designates a consistent set of services and functions, 

- the expression "application software" designates the software needed to perform the 
15 functions relating to a given application, and 

-a secure transaction is a transaction for which security measures are implemented, 
namely authentication of the entities participating in the transaction, integrity, confidentiality, 
authenticity and possibly non-repudiation of exchanges and operations effected in the context of 
the transaction. 

20 Many applications require secure electronic transactions. Examples are controlling 

access to computer or similar resources, home banking (statements, transfers between 
accounts, etc ... via the telephone network or the Internet), electronic trading (purchase of goods 
or services via a public network), electronic mail, electronic purse, etc. 

These and other applications requiring secure transactions are well known to the 

2 5 skilled person and are not described in detail here. 

Depending on their nature, rendering such applications secure necessitates the use of 
one or more security services such as: 

- authentication, to guarantee the identity of an entity (a person or a system); 

- access control, protecting against unauthorised use or manipulation of resources; 

3 o - confidentiality, prohibiting disclosure of data to unauthorised entities; 

-data integrity, which assures that data has not been modified, deleted or substituted 
without authorisation, and 

-non-repudiation, which assures that a participant in an exchange of data cannot 
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subsequently deny the existence of the exchange. 

The combination of two existing techniques makes it feasible to employ the above 
security services, so offering a sufficient level of security for the performance of electronic 
transactions. 
5 These are: 

- public key and private key cryptography, because it guarantees non-repudiation and 
facilitates management of keys; and 

- the integrated circuit card (or smart card), because it is relatively inexpensive, easy to 
use and reliable because it uses dedicated microprocessors with hardware and software 

10 protection features so that read and write mode access to their memory can be barred. 
Integrated circuit cards offer the following services: 

* authentication of the cardholder or user: this operation authenticates the cardholder 
by means of a confidential code after which the card allows operations such as executing 
algorithms, reading secret keys, reading or writing data on the card, which can also be subject to 

15 other security conditions; 

* protection of data and functions stored on the integrated circuit card. Access to the 
card can be subject to prior authentication of the electronic entity requesting to access it. This 
external authentication is generally effected in challenge/response mode. In this case the entity 
has a secret parameter, hereinafter also called the secret, enabling it to calculate, depending on 

20 a challenge issued by the card, a response that will prove to the card that it is in possession of 
the secret; 

* execution of cryptographic algorithms using a secret parameter stored on the card 
(encipherment, message authentication, signature); and 

* internal authentication. This service enables an application to authenticate the card. 
25 This service is the inverse of external authentication. The card generates a response to a 

challenge received and a secret stored on the card. 

The services offered by means of the integrated circuit card are performed on receipt of 
so-called elementary commands, execution of the elementary command causing the sending of 
elementary responses. The elementary commands concern, for example, cryptographic 
3 0 calculations, reading or writing of secret or other data, intervention of the user (entry of their 
personal confidential code (PIN), validation of a transaction after signature), and return of 
information to the user (display of messages to be signed, for example). 

Some cards offer the facility to verify the integrity, source and even the confidentiality of 
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commands sent to the card. These services are based on techniques of authenticating and 
enciphering the commands. 

The current use of integrated circuit (or microcircuit) cards offers a very high level of 
security because the transactions are essentially performed on private networks and terminals 
5 (automatic teller machines, point of sale terminals, for example) which are under the control of an 
entity assuring the security of the system as a whole. 

In such applications, users or abusers do not have access to the application software 
or to the hardware and software security mechanisms of the terminals. 

In contrast, performing secure transactions using integrated circuit cards on a public 
10 network presupposes that users have access to a card reader terminal module, given that 
microcircuit cards do not have their own electrical power supply and that using them requires a 
reader that can power them up and establish communication with the user and/or external 
electronic means. 

At present, to perform a transaction on a public network, the user employs a terminal 
15 that can be a dedicated product, a personal computer or a personal computer connected to an 
integrated circuit card by a card reader. 

In all cases, the transaction system accessible to the user generally comprises: 
•an application service provider, for example an Internet browser, an electronic mail program, a 
home banking program, 

20 «a high-level security service provider enabling execution of low-level cryptographic mechanisms 
required by the application. 

The application service provider issues requests for high-level security services to 
assure the security of the transactions performed. 

If the application is installed on the user's personal computer, the cryptographic 

2 5 services referred to are, for example, those defined by RSA laboratories in its standard "PKCS 

11 : Cryptographic Token Interface Standard" or the cryptographic services, offered by the 
Microsoft Windows NT operating system, in particular those available via the "Crypto API" 
application program interface (API). 

If the user does not have an integral microcircuit card reader, the cryptographic 

3 o services are effected entirely by software. 

If the user wishes to enhance security, they use a transparent type integrated circuit 
card reader connected to their computer. A transparent type card reader is in fact an interface 
module between the computer and the integrated circuit card for transmitting elementary 
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commands from the computer, originating from the cryptographic service provider, to the card, 
and elementary responses from the card to the computer. Using this terminal, consisting of their 
terminal module - computer + reader - coupled to their card, a user can perform electronic 
transactions (electronic shopping, for example). 
5 Of course, access of users to a terminal of this kind generates potential security risks. 

The more decentralised the applications the greater the risk. Conversely, the better the 
control of the risks at the terminal end, the more decentralised can the applications be. Consider 
purse type applications, for example, in which transactions (purchaser card debit/merchant card 
credit) are effected card-to-card, without requiring consolidation of the transactions at the level of 

10 a centralised server. 

It follows from the foregoing discussion that a terminal can potentially contain a set of 
information (or even software) on whose confidentiality and integrity the security of the 
application relies. Consider, for example, secret keys used to authenticate the terminal modules 
vis k vis the card or to encipher data transferred between a server and the card reader terminal 

15 module. An abuser with access to the terminal can analyse its operation and obtain access to 
the confidential information and software. 

Note also that the applications referred to here, such as electronic shopping and 
electronic mail, are usually performed via the Internet. Experts are well aware that a personal 
computer (PC) connected to the Internet is highly vulnerable to viruses which can be installed 

2 o and execute on the user's PC without them knowing it and without them allowing physical access 
to their computer to anyone at all. The totally invisible nature of this type of threat is the real 
danger currently limiting the deployment of transaction-based applications using the Internet. 
The same comments apply to electronic shopping applications on^ cable TV networks using set- 
top boxes connected to the TV set and incorporating one or two smart card readers. 

2 5 The system level risks are then: 

• Attack on the integrity of the cryptographic service provider and the application 
service provider with the aim of modifying the behaviour of the terminal module: for example, the 
terminal module is modified to capture information associated with the card and to store the 
information obtained for subsequent communication to a counterfeit server. This attack can be 

3 o carried out unknown to the legitimate user (substitution of the user's terminal module or loan of a 

modified terminal module). This attack can then be generalised by circulating counterfeit 
terminal modules. 

• Attack on the confidentiality of the cryptographic service provider, with the aim of 



obtaining the cryptographic keys they use, which are stored on the hard disk of a computer, for 
example. 

• Attack on other cards, based on the ability to authenticate the abuse vis a vis other 
cards by virtue of the secrets discovered by attacking the confidentiality of the service provider. 

• Attack on the integrity and the confidentiality of communications between the various 
entities (application service providers, cryptographic service providers, integrated circuit card 
reader, integrated circuit card, server) to break the chain of confidence established between 
these elements. For example: 

1 - deciphering communications between server and terminals; 

2 - inserting third party software between the application service provider and 
the cryptographic service provider to break the chain of confidence between these two programs 
or to substitute for the application software third party software causing the security service 
provider to execute security requests with a different aim to that of the application known to the 
user. 

• Attack on servers (in the case of an on-line application): connection of a counterfeit 
terminal to a server, emulation of a terminal module/integrated circuit card combination to obtain 
advantages. 

An attack on the chain of confidence between the cryptographic service provider and 
the application service provider in the context of an application requiring an electronic transaction 
using an integrated circuit card to be signed is illustrated hereinafter. The transaction proceeds 
as follows: 

- Step 1 : verification of the personal confidential code (PIN) of the user, entered by the 
latter via a keypad associated with their terminal module, the code entered being sent to the card 
for verification by the latter. 

-Step2 : authentication of the terminal module. The latter sends a "challenge request" 
command (a challenge is a random or pseudo-random number), the integrated circuit card 
generates the challenge and sends it to the terminal module. The terminal module sends the 
card an "external authentication" command accompanied by a response consisting of the 
challenge enciphered by a key held by the terminal module. The integrated circuit card then 
verifies the response received. 

- Step 3: if steps 1 and 2 are executed satisfactorily, the integrated circuit card is ready 
to receive and to execute the signature command, i.e. command of encipherment, using a secret 
key stored on the card, of the result of a hashing operation performed on the transaction entered 



6 



by the user. After this encipherment the card sends to the terminal module the signature 
consisting of the result of the hashing operation enciphered in this way. 

If the integrity of the application software (application service provider and its 
cryptographic service provider) is not assured, a hacker does not need to know the secret code 
5 and keys to pirate the transaction system; all that is necessary is to implant in the terminal 
module, for example the personal computer to which an integrated circuit card reader is 
connected, virus type software which in step 3 diverts the authentic data to be signed and sends 
falsified data to the card. Given that steps 1 and 2 have been executed in a satisfactory manner, 
the card will then sign the falsified data on the basis of the PIN that the user has entered and the 

1 o user will believe that the card is about to sign their own data. 

The preceding example shows the necessity of protecting not only the confidential 
information used in the context of a transaction but also the integrity of the transaction, i.e. the 
integrity of the behaviour of each entity involved in the transaction, together with the integrity of 
the behaviour of all of the software, assuring that the chain of confidence established between 
15 the various entities is broken. 

The risks of attack mentioned hereinabove are currently covered in part by terminals - 
integrated circuit card readers integrating security modules (SAM, similar to an integrated circuit 
card) used in the context of purse applications in particular. The reader is then personalised by 
a SAM and assigned to a merchant, the cards read being those of customers. The SAM 
20 contains secret information and is able to execute algorithms using the secret information. 
However, it does not contain means for controlling communication with the user, with the 
integrated circuit card and/or with external electronic means, and for this reason the security of 
transactions is not assured. 

Document WO 95/04328 discloses a terminal module comprising user interface means 

2 5 and interface means to external electronic means (hereinafter called external interface means) 

including an interface with a microcircuit card. The microprocessor of the terminal module 
comprises data storage means (ROM, EEPROM, RAM). The data stored in permanent memory 
(ROM) includes an operating system, managers of external components controlling the 
interfaces and peripheral devices, and an interpreter capable of interpreting program modules 

3 o written in a specific language. The program modules are stored in the semi-permanent memory 

EEPROM and can be loaded into temporary memory RAM to be executed by the microprocessor 
on activation of an appropriate interface by the user. The program modules corresponding to the 
applications of the terminal module are downloaded into the EEPROM of the microprocessor or 
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into a microcircuit card from an external server. 

The terminal module of document WO 95/04328 can operate: 

-in autonomous terminal module mode, the microprocessor of the terminal module 

executing a program module stored in an internal memory without calling on an integrated circuit 
5 card; : 

-in autonomous terminal mode, in which a program module stored on a card is 

executed; 

-in extended terminal mode or on-line mode, in which the microprocessor of the 
terminal module or that of the card executes a program module and communication is 
10 established via the telephone, a modem or a direct connection to a service provider or a server; 
and 

- in transparent memory card reader mode, in which instructions received over a serial 
link are sent directly to the card and vice versa. 

The terminal described in document WO 95/04328 does not deal with security 
15 problems addressed by the invention in that there is no description of how to secure a 
transaction to guarantee the integrity of the behaviour of all of the software executing the 
transaction. In particular there is no description of means for executing high-level requests 
issued by the application or how to guarantee the source, the integrity and the confidentiality of 
such means. 

20 The present invention aims to provide a terminal for carrying out secure electronic 

transactions of the type comprising a personal security device such as an integrated circuit card 
or other device fulfilling the same functions and a terminal module provided with means of 
interfacing the personal security device, such as an integrated circuit card reader, and offering by 
virtue of its software and/or hardware architecture and the security mechanisms that it includes 

2 5 an enhanced level of security compatible with the fact that the terminal can be under the control 

of users (as opposed to terminals under the control of the operators). 

A second objective of the invention is to assure this same level of security whilst 
enabling integration, during use, of new functions or applications, or modification of existing 
functions or applications without having recourse to a multitude of different terminal modules and 

3 o without changing terminal modules to effect such modifications. 

To this end, the invention consists in a terminal for execution of secure electronic 
transactions by a user in conjunction with at least one application installed on an electronic unit, 
said terminal comprising: 
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- a terminal module including at least: 

* first interface means with said application for receiving from it requests 
relating to said transactions, 

* second interface means with said user; 

* third interface means with a personal security device, 

* first data processing means comprising at least first software means for 
controlling said interface means, and 

-a personal security device including at least second secure data processing means 
comprising at least second software means for executing elementary commands and means for 
executing cryptographic computations, 
characterised in that: 

- said terminal is adapted to receive said requests from said application installed on 
said electronic unit in the form of high-level requests independent of said personal security 
device, 

- at least one of said terminal module and said personal security device comprises: 

* at least one programmable memory for storing at least one filter program for 
translating said high-level requests into at least one of either (i) at least one command or a 
sequence of elementary commands for being executed by said second software means of said 
second data processing means, or (ii) at least one sequence of data exchanges between said 
terminal module and said user via said second interface means, said data exchanges being 
executed by said first software means of said first data processing means, 

* means for protecting said filter software to prevent an unauthorised person 
reading and/or modifying said software, and 

- at least one of said first and said second data processing means comprise a data 
processing device for executing said filter program. 

The invention defined hereinabove achieves the security objectives required for 
carrying out electronic transactions by virtue of the fact that it describes a filter or ■firewall" 
between the external world, i.e. the applications themselves, and the security means and 
peripheral devices that it controls, by means of a logical interface defining the format of high- 
level requests issued by the applications and of a translation software for processing these 
requests. 

The terminal of the invention preferably comprises one or more of the following 
features, possibly in combination: 
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-said device for executing the filter program comprises first means for identifying 
and/or authenticating said application installed on said unit or the source of said requests sent by 
said application, 

-said data processing device for executing said filter program comprises means for 
5 verifying the integrity of data received from said application, 

- said data processing device for executing said filter program comprises centralised 
means for controlling conditions of use of services of the personal security device in accordance 
with said application and/or the user, 

- said data processing device for executing said filter program comprises: 

10 * means for commanding secured loading of said filter program into said 

programmable memory via said first or said third interface means from an entity external to said 
module, and 

* first access control means for authorising said loading of said filter program 
only in response to at least one predefined condition, 
15 - the terminal comprises second means for authentication of said first data processing 

means by said second data processing means, 

- the terminal comprises third means for authentication of said second data processing 
means by said first data processing means, 

-the terminal comprises a first communication channel between said first data 
20 processing means and said second data processing means and first means for securing said 
first communication channel, 

- the terminal comprises fourth means for authentication of said terminal module by 
said user, independently of said card, 

- said fourth authentication means comprise means for calculation by said first data 

2 5 processing means and for presentation to said user via said second interface means of a 

password known to said user and computed on the basis of a first secret parameter stored in 
said first data processing means, 

- the terminal comprises fifth means for conjoint authentication of said terminal module 
and said card by said user, and 

3 o - said fifth authentication means comprise means for computation by said device for 

executing said filter program and for presentation to said user via said second interface means of 
a password known to said use and computed on the basis of at least second and third secret 
parameters stored respectively in said first data processing means and said second data 
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processing means. . 

In a first embodiment of the invention the terminal module is a personal computer and 
said programmable memory is the hard disk of said computer, said filter software is executed on 
the personal computer, or in a second mode of execution said programmable memory is on a 
5 secure server connected to the personal computer, the part of the filter software to be protected 
being executed on said secure server. 

In a second embodiment of the invention the terminal module is a device such as a 
dedicated integrated circuit card reader, in which case said personal security device is an 
integrated circuit card or a personal computer. This embodiment differs from the preceding one 
10 in that said programmable memory is integrated into a secure microprocessor, said filter software 
being executed in said secure microprocessor. The dedicated terminal module can be portable. 

Depending on the mode of execution of this second embodiment of the invention, the 
programmable memory for loading and storing the filter software can be in the personal security 
device or in the terminal module. In the latter case: 
15 - the terminal module can include a single microprocessor for executing the filter 

software and for controlling the interfaces or two microprocessors respectively implementing 
these two functions ; 

- preferably, said filter program comprises at least one secret parameter, and said 
second data processing means . comprise second means of conditional access control for 

2 o authorising execution of said cryptographic computations in response to elementary commands 
generated by said filter program only if at least a second predefined condition depending on said 
secret parameter is satisfied. 

According to other features of the invention, when the terminal module comprises two 
microprocessors for executing the filter software and for controlling the interfaces : 

2 5 - the terminal comprises a second communication channel between said first software 

means for controlling the interface means and said microprocessor and second means for 
securing said second communication channel ; 

- said second securing means comprise means for encryption and decryption, by said 
first software means for controlling the interface means and said second microprocessor, of data 

3 0 sent on said second communication channel on the basis of at least a fifth secret parameter 

stored in memory on said storage means ; 

- said second securing means comprise first physical means for protecting said second 
communication channel against intrusion. 
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Various embodiments of the invention will now be described with reference to the 
accompanying drawings, in particular embodiments in which the filter software is loaded and 
executed in the terminal to guarantee its source, its confidentiality and its integrity, the software 
being also able to authenticate the source of requests sent to it if confidence in the interfaces 
5 with the user, i.e. the screen and the keyboard, cannot be guaranteed. 

- Figure 1 is a diagram showing the functional architecture of a system for carrying out 
secure transactions by means of a terminal in accordance with the invention; 

- Figure 2A shows a first embodiment of the invention in which the terminal is a 
personal computer connected to an integrated circuit card by a reader, the application being 

l o installed on the personal computer or on a remote server; 

- Figure 2B explains the functional architecture of one variant of the first embodiment of 
the invention in which the personal computer serving as a terminal is connected to a security 
server on which the filter software is installed; 

-Figure 3 shows a transaction system using a terminal constituting a second 
15 embodiment of the invention, which can be a dedicated product connected as a peripheral 
device to a personal computer or directly to a server or based on a personal computer; 

- Figure 4A is a block diagram of the hardware architecture of the electronic circuits of a 
first mode of execution of the terminal from figure 3; 

- Figure 4B is a functional diagram illustrating a first software architecture configuration 
20 of the terminal from figure 4A; 

- Figure 4C is a functional diagram similar to that of figure 4B showing a second 
software architecture configuration of the terminal from figure 4A; 

- Figure 5 is a block diagram of the hardware architecture of the electronic circuits of a 
second mode of execution of the autonomous terminal from figure 3; 

25 - Figure 6 is a block diagram of the hardware architecture of the electronic circuits of a 

third mode of execution of the autonomous terminal from figure 3; 

-Figure 7 is a diagram illustrating the conventional software architecture of a 
microcircuit card; 

- Figure 8A is a diagram illustrating the software architecture of a transaction system 
3 o comprising the terminal from figure 4A; 

- Figure 8B is a diagram illustrating the software architecture of a transaction system 
comprising the terminal from figure 6; 

- Figure 9 is a diagram illustrating the implementation of an electronic trading 
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application by means of a system in accordance with the invention; and 

-Figure 10 is a flowchart showing the process of downloading a program into a 
reprogrammable memory of the terminal module from figure 4A or figure 5 or of a microcircuit 
card connected to the latter. 
5 Referring to figure 1, a system for carrying out secure transactions comprises a 

terminal module 1 for reading an integrated circuit card 31 or the like. The terminal module 1 
comprises a filter F consisting of a software module processing high-level requests issued by 
application service providers FAp external to the terminal module 1 by means of a logic interface 
F-APl and user interfaces such as a display screen 4 and a keyboard 5 enabling a user to read 

1 o and enter data. It also comprises a reader or other communication interface 6 with a microcircuit 

card or any equivalent security device personal to the user of the token, "Java Ring" (from SUN), 
"iButton" (from Dallas Semiconductor Corporation), or soft token type and communication 
interfaces with at least one application service provider FAp which can be installed on a PC 
and/or on a server Sap, for example, data then being exchanged via a data communication or 
15 telecommunication network R. 

The terminal module 1 can be a dedicated terminal or integrated into a PC or into a 
network computer (NC) dedicated to network applications or into a cable TV network decoder 
(Set Top Box). 

The terminal module 1 can perhaps be used in autonomous mode, for example to read 

2 o information such as the contents of an electronic purse contained in a memory of the card 31 . 

To carry out secure transactions the terminal module 1 can be used on-line to a server 
Sap or off-line, the application FAp then running locally, for example on the PC: this is the case 
when, for example, a user must sign an electronic mail message or transactions that will be sent 
to an addressee. An operation of this kind does not imply connection to an application server at 

2 5 the time when the card 31 is used. 

In on-line mode, as represented in figure 3 in the case of a dedicated terminal module 
1 , the latter can be connected to the server Sap on which the application FAp is installed via the 
PC and a network R such as the Internet or through the intermediary of the telephone network R 
via a modem MO or a DTMF link with a telephone handset CT. Some transactions, such as 

3 o reloading an electronic purse in the card 31 , can necessitate bidirectional exchange of data with 

the server Sap and are therefore more ergonomic in on-line mode. 

Carrying out a transaction secured with a terminal module 1 and a card 31 implies that 
high-level software requests (for example: requests for signature, authentication, etc... which 
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must be processed so as to meet the required security objectives of the application program) will 
be sent from the application program installed on the server Sap for example (on-line mode) or in 
the PC or NC available to the user (off-line mode, for example signing of electronic mail) to the 
filter F controlling the security means. The filter F processes these requests by means of 
5 translation software to assure that the application or virus type software cannot have direct 
access to the cryptographic functions of the integrated circuit card 31. The processing of the 
high-level requests includes translation of these requests into an elementary command or a 
sequence of elementary commands which are executed by the personal security device. The 
high-level requests are formulated independently of the software and/or hardware design of the 
10 personal security device, i.e. they are not formulated as a direct function of the personal security 
device. 

The high level requests contain information specifically related to the process that will 
be executed by the filter F. In a simple example, a high level request can contain a single 
elementary command to be transferred to the personal security device, for example, an APDU 

15 (Application Protocol Data Unit) in the case of a smart card, attached to a Message 
Authentication Code that will enable the filter F to check the origin and integrity of this request 
before sending the elementary command to the personal security device. In a more complex 
example such as a request to sign a document, the high level request will be transformed by the 
filter F into a sequence of elementary commands sent to the personal security device, and 

20 eventually to the user interface. Thus, according to this definition and due to the fact that it 
contains specific information to be decoded by the filter F independently of the personal security 
device, the high level requests will be said to be independent of the personal security device. 

The filter F meets the security objectives required in that the translation software that it 
includes verifies the identity of the application issuing the service requests (or the source of 

2 5 requests directly) and is installed in a manner that guarantees the integrity and the confidentiality 

of the operations and data used to respond to service requests. 

A translation software is configured for one type of microcircuit card and translates a 
high-level request received from application software into an elementary command or a 
sequence of elementary commands that can be executed by the microcircuit cards and/or a 

3 o sequence of exchanges of data with the user. 

The high-level requests are a list of commands used by the application programs to 
invoke the security services needed to identify and authenticate the person performing the 
transaction and to guarantee the source, the integrity and where applicable non-repudiation of 
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the transaction. A high-level request from an application (on a server or on the PC or NC) can 
be characterised by one or more of the following points : 

- it is independent of the basic means (cryptographic means, for example) used to 
respond to its request and contains specific information to be processed by the filter F. 

5 Reciprocally, a plurality of applications can use the same security service provider, employing 
the same logic interface F-API defining these requests. 

- the processing of the request links the transaction in a certain manner to the user 
performing the transaction by means of at least one fixed or variable secret parameter stored in 
by the integrated circuit card of the user. 

10 -it can include information enabling the filter software F to verify its source and its 

integrity. Authentication can use a Message Authentication Code (MAC) or a code of the 
electronic signature type associated with the request. 

- if the transaction is not entered by the user on the terminal module itself, the request 
can contain the information needed for the user to verify the essential data of the transaction, if 

15 required and if the terminal module supports this option. 

The logic interface F-API for exchanging high-level security requests between the 
application and the translation software of the filter F can be standardised so that it is common to 
different application programs. Accordingly, the signature type request can be used by an 
electronic mail application and by purchasing software. . It is therefore possible to change the 

2 o application whilst retaining the security service provider or vice versa to replace the security 

service provider without changing the application. 

To guarantee the integrity of the chain of confidence between the application and the 
card, the translation filter software F identifies and even authenticates the source and the 
integrity of requests that it receives. Various methods are feasible for identifying the application 
25 issuing the requests: 

- an identification code can be integrated into the request itself and then verified by the 
filter software using information that it contains or that can be stored on the integrated circuit 
card; 

- the same objective can be achieved by comparing the result of a hashing operation 

3 o executed by the filter software on the application software issuing the request with a result 

previously stored on the card, for example. This solution is particularly suitable for the situation 
in which the application is installed on the user's PC; 

-authentication can equally be performed by associating with the request a MAC 
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calculated from the content of the request and a secret key shared between the application and 
the filter software. An equivalent principle can be used with a signature on the request 
calculated with the same information and a private key known to the application, the signature 
being verified with the corresponding public key known to the filter software. 
5 Figure 2A explains a first embodiment in which the terminal module 1 is a PC 102, the 

connection to the integrated circuit card 31 employing a reader 6 connected to or integrated into 
the PC 102. The PC 102 includes input/output interfaces 102a to the reader 6 and the server 
Sap. Depending on the nature of the reader connected to the PC, the user interface 
components can be the keyboard and the screen of the PC itself or a keyboard and/or an LCD 

1 o display on the reader, for example. In this embodiment the filter F is installed and executes on 

the PC 102. The filter F, and therefore the translation software that it contains, can be stored on 
the hard disk (HD) 102b of the personal computer 102. To execute on the central processor unit 
or microprocessor 102c of the PC, the filter software is loaded into the random access memory 
(RAM) 102d of the personal computer 102. 
15 Because the hard disk of a PC is difficult to protect, the filter software F or at least the 

sensitive part of this software can be encrypted. For this purpose it can be divided into at least 
two modules: a loading/decrypting module Fed and a second module corresponding to the 
encrypted filter software itself. The first module enables the second module to be loaded into 
RAM, decrypted and. then executed. Referring to figure 2A, the software module when 

2 o decrypted and loaded into RAM is denoted Fdec. 

Programming languages like Java, with security mechanisms intrinsic to the language 
itself, strengthen the protection of the software. 

Another method of verifying the integrity of the filter software is to have the second 
module signed by an authority guaranteeing the content of the filter software by means of a 

2 5 private key that is kept secret by the authority. The first loading module then, at the same time 

as performing the decrypting operation, performs a hashing operation on the second module and 
verifies the signature of this module using the public key associated with the private key of the 
authority. 

The operations described above imply the use of keys on which the security of the 

3 o application relies. These keys can be concealed in the loading module, stored in the reader 6, or 

stored on the integrated circuit card 31 itself. Another possibility is to install the decryption and 
integrity verification module in the reader 6. 

The object of the invention is to prevent a pirate from using the integrated circuit card of 



16 



a user without their knowledge, for example by modifying the filter software controlling the card 
or the application software, or by loading a virus to bypass the application or the filter software. 
The embodiment described previously and its variants address these risks, by enabling 
verification of: 

5 - the integrity of the filter software, and 

- the source and the integrity of commands sent to the card via the reader 6, by 
authenticating them using a MAC, for example. The MAC can be verified by the reader 6 or the 
card 31 . Equivalent protection could be obtained by encrypting the dialogue between the filter 
software and the reader 6. A virus attempting to bypass the filter software would then send 
10 unauthenticated or incorrectly encrypted commands to the reader 6 or to the card 31; these 
commands would therefore be rejected by the reader or the card, preventing the virus from 
achieving its aims. To prevent a hacker from determining the keys used by a terminal by 
analysing the operation of another terminal, the keys used by various terminals must be 
diversified. 

15 The encryption and signature mechanisms that can be considered to address the need 

to protect the filter software are well known to the skilled person and are based on existing 
cryptographic techniques as described, for example, in "Applied Cryptography, Protocols, 
Algorithms, and Source Code in C" by Bruce Schneier, John Wiley and Sons, Inc., 1994 and for 
this reason will not be described in detail here. 

2 o Installing the filter software on a PC cannot guarantee the same level of security as 

installing it in a dedicated terminal that can offer additional hardware security mechanisms as 
used in the other embodiments described later, these mechanisms offering physical protection of 
the filter software and the secrets that it contains. 

Figure 2B shows one variant of the figure 2A embodiment. This variant exploits the 

2 5 flexibility and the ease of connection of a personal computer to a network. This enables part of 

the filter software, and in particular the secrets, to be held by a secure server Ssec. 

In figure 2B the filter software is divided into two software modules, a module F-PC 
installed on the PC 102 and a module F-SE installed on a security server Ssec. The 
programmable memory previously referred to and storing the filter software is therefore in the 

3 o secure sever Ssec in this variant, i.e. out of reach of unauthorised users. Likewise, the filter 

software or at least the sensitive part of the filter software F-SE requiring protection executes on 
the secure server Ssec. 

The software module F-PC installed on the PC 102 is connected by a secure channel 
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CS to the security server Ssec. The secure channel is an encrypted communication channel for 
exchanging protected data between the two filter software modules F-PC and F-SE and possibly 
reciprocal authentication of the two modules F-PC and F-SE. The secure channel can use well- 
known communication protocols such as SSL, for example, 
5 Setting up this secure channel CS therefore enables the first filter software module F» 

PC to send to the second filter software module F-SE requests received from the application FAp 
via the logic interface F-API together with information concerning identification of the application 
issuing these requests. After verifying the information relating to the application, and depending 
on the application and possibly on rights of the user, the second software module F-SE then 

10 translates these requests into a series of commands to the microchip card 31 and for controlling 
exchanges of data with the user, The commands generated by the module F-SE are then sent 
to the first module F-PC which routes them to the element concerned: the PC itself in the case of 
the commands controlling exchanges with the user or the integrated circuit card. For the 
commands controlling exchanges with the user to execute on the PC, the latter must include an 

15 interpreter software module I. The interpreter software enables display of messages on the 
screen 4 and input of information by the user via the keyboard 5. The interpreter software 
module is described in more detail in connection with figures 4B and 4C. 

This second mode of execution is based on the mechanisms described a propos the 
first mode of execution (figure 2A) insofar as the identification of the application (hashing or 

20 signature, for example) and protection of commands sent to the card (addition of a MAC, for 
example) are concerned. On the other hand, it offers an enhanced degree of security insofar as 
the filter software module F-SE translating high-level requests received from the application FAp 
executes in a secure environment. In the context of the invention the server Ssec is deemed to 
be secure if it is not accessible physically or logically (i.e. via a network connection) to 

2 5 unauthorised persons. 

The second mode of execution shown in figure 2B is suitable for applications employed 
in a closed or private environment controlled by a central authority, as it necessitates a protected 
server administered centrally. This second mode of execution also offers the facility to define a 
centralised policy of access to cryptographic services offered by the integrated circuit card. This 

3 o access policy can be based on applications requiring the services of the card and on the users 

themselves. In the case of a business issuing its employees or customers integrated circuit 
cards enabling them to sign electronic mail and banking transactions, it can assure that only 
authorised users can sign: this mechanism can be implemented using the secure channel CS. 
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For each signature request issued by one of the applications deemed to be valid by the business 
(the electronic mail program and the bank transaction software), the software module F-SE will 
execute a request for authentication of the user. This request can be executed, for example, by 
sending a random number (challenge) to the card 31 via the secure channel CS. After the user 
5 enters their confidential code, the integrated circuit card calculates a dynamic password by 
encrypting the challenge using a secret key that it holds. The password is then sent via the 
secure channel CS to the software module F-SE. Knowing the user and therefore the secret key 
held on their card, the software module F-SE compares the password received with the 
password expected. This mechanism, known as challenge-response mode authentication, 

10 enables the software module F-SE to validate the user's identity. Thus the business that has 
issued the integrated circuit cards to the users can assure that only users who are still authorised 
can sign bank transactions, for example. 

By virtue of the secure and centralised means that it represents, the server Ssec 
enables not only secure installation of the filter software F-SE but also the facility of instituting a 

15 centralised policy for controlling use of security services offered by the integrated circuit card. 
The server Ssec enables a centralised policy to be instituted by virtue of the fact that the same 
server can be connected to a plurality of software modules F-PC installed on the personal 
computers of a plurality of users. Thus the server Ssec enables centralised definition and control 
of the conditions of use of security services offered by the cards issued to the. various users in 

2 o accordance with the profile of the application requesting the services and the rights of said users. 
Instituting this centralised policy implies the server holding the necessary information, i.e. the 
rights of users to use a particular security service in connection with a particular application. 

This second mode of execution (figure 2B), well suited to private environments, is 
difficult to apply to open applications where a secure central server Ssec is not feasible. 

2 5 Figure 3 shows a terminal module embodying functional architecture principles similar 

to those of figure 2B in a different embodiment requiring no centralised server. The terminal 
module in the second embodiment of figure 3 has a very high level of security, enabling it to 
assure local protection of the filter software F directly. 

In figure 3 one face of the terminal module 1 which can be a portable unit, carries the 

3 o display screen 4 and the keyboard 5 and the unit contains the electronic circuits, which are 

preferably not accessible from the outside. The module 1 contains the reader 6 and has an 
opening for inserting the microcircuit card 31 into the reader 6. The mode of execution described 
with reference to figures 3, 4A, 4B and 4C must not be considered as limited to a dedicated 



19 



terminal. The following description applies to a PC-based or NC-based terminal. 

In a first mode of execution, shown in figure 4 A, of this second embodiment of the 
terminal module of figure 3, the electronic circuits of the terminal module 1 are based on a 
standard microcontroller 2 and a secure microprocessor 3 which are interconnected and 
5 permanently installed in the module 1. As an alternative to this, the microprocessor 3 can plug 
into the module 1 by means of a connector 41 shown in dashed line in figure 4A. This 
description covers a generic mode of execution based on a standard microcontroller. In a 
particular mode of execution that will be described later the microcontroller 2 can be a PC 102 of 
the type shown in figure 2B. 

10 The standard microcontroller 2 comprises a processor unit 2a, temporary memory 

(RAM) 2b and permanent memory (ROM) 2c. It is preferably a "monochip" microprocessor the 
software of which is mask-programmed in the permanent memory 2c and which integrates into 
the same integrated circuit standard interface management or control means, the processor unit 
2a, the temporary memory 2b and the permanent memory 2c. 

15 The interfaces or peripheral devices managed by the microcontroller 2 include the data 

display screen 4, for example a liquid crystal* display, the keyboard 5 for entry of data by a user, 
the microcircuit card reader 6, an external connection interface 7, for example of the RS 232 or 
PCM-CIA type, an infrared link interface 8 and a DTMF device 9 for sending data over a 
telephone line. 

20 The components of the module 1 also include a clock 10 and an electrical power 

supply 1 1 for the various circuits and components of the module 1 . The electrical power supply 
1 1 can be a battery power supply if the module 1 is portable and autonomous. 

The task of the standard microcontroller 2 is to manage the environment, i.e. to control 
the interfaces 4-9 and the clock 10 together with the power supply 11 for selectively energising 

2 5 the secure microprocessor 3 in the case of an autonomous module 1 . 

The standard microcontroller 2 therefore requires little computing power, little 
temporary memory (RAM) and no semi-permanent memory (EPROM OR EEPROM). The 
microcontroller 2 is write protected by virtue of the fact that programs (interface control and, as 
described below, interpretation, management of clocks and electrical power supply, etc) are 

30 mask-programmed in the permanent memory 2c. As will become apparent hereinafter, the 
standard microcontroller 2 can also contain one or more secret parameters on the basis of which 
it can be authenticated by the secure microprocessor of the terminal module and/or of an 
integrated circuit card. The secrets must therefore be protected against reading and writing. 



They are preferably stored in the temporary memory (RAM) of a "monochip" microprocessor 
which cannot be written or read from the outside. The standard microcontroller 2 can also have 
additional security functions, for example to prevent fraud such as display of data different to that 
coming from the microprocessor 3. 

It is therefore of low cost and consumes little electrical power, which is particularly 
suitable for a portable product. The microcontroller can be an OKI MSM 63180, for example. 

There are preferably two clocks 10: a low-frequency clock 10a, for example a 
32.368 kHz clock, and a high-frequency clock 10b, for example a clock at 1 MHz to 12 MHz. 
The microcontroller 2 commands the connection of its system clock to one or other of these two 
clocks. 

The slow clock 10a times a timer 2d of the microcontroller 2 with a period of 0.5 s to . 
provide a real time clock in the module 1 . The processor unit 2a can also use the slow clock 10a 
for functions that do not require high calculation speed: in this case the system clock of the 
microcontroller 2 is connected to the slow clock 10a and the fast clock 10b is stopped. This 
mode of operation reduces the electrical power consumption of the module 1 which is 
advantageous if it is portable and battery powered. 

The microprocessor 3 which is read and write protected includes a central processor 
unit 3a, a temporary memory (RAM) 3b and a permanent memory (ROM) 3c, together with 
electrically reprogrammable semi-permanent memory (EEPROM or Flash RAM, for example) 3d 
for storing the application programs of the module 1 . 

The secure microprocessor 3 is of the type used in microcircuit cards and has a limited 
number of inputs and outputs, its internal buses being inaccessible from the outside. It is 
manufactured with other security mechanisms specific to this type of microprocessor and well 
known to the skilled person, such as security matrix, memory scrambling, clock frequency 
control, reset control, etc mechanisms. 

Because the microprocessor 3 has a semi-permanent memory 3d it is possible to load 
one or more application programs into it from the outside, for example from a server or from a 
microcircuit card. It is therefore possible to modify the application(s) in accordance with 
requirements (access control, financial and/or commercial transactions, electronic purse, etc) for 
which the module 1 is intended. If the size of the semi-permanent memory 3d allows it, it is also 
possible to install new applications during its use. 

Depending on the version chosen, the secure microprocessor 3 can compute 
cryptographic functions requiring large-scale computations embodied in RSA or DSA type 
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asymmetric algorithms or use simpler algorithms, for example DES type algorithms. 
The secure microprocessor 3 can be, for example: 

- a SIEMENS SLE44C160S non-cryptographic micro-processor, with 14 kbytes of ROM 
and 16 kbytes of EEPROM; 

5 -an SGS THOMSON ST16CF54A cryptographic micro-processor, with 16 kbytes of 

ROM, 4 kbytes of EEPROM and 480 bytes of RAM; 

- a PHILIPS P83C858 cryptographic microprocessor with 20 kbytes of ROM and 
8 kbytes of EEPROM. 

The secure microprocessor 3 is connected by the link 12 to the standard 
10 microcontroller 2 and by links 13 and 14 to the external interface 7 and to the microcircuit card 
reader 6 via respective switches-interface adapters 15 and 16. The switches-interface adapters 
15 and 16 are controlled by the standard microcontroller 2 via respective links 17 and 18. 

The standard microcontroller 2 comprises an interpreter program 20 (figs 4B and 4C) 
stored in the ROM 2c and enabling it to execute commands generated by the software for 
15 translating high-level requests forming part of the application or program(s), as described 
hereinafter. The interpreter 20 enables application programs stored in the secure 
microprocessor 3 to control the interfaces 4-9 via the link 12. The application programs can 
nevertheless be located and executed elsewhere than in the secure microprocessor 3, for 
example on a microcircuit card 31 inserted into the interface 6, for example a card supporting 

2 0 mechanisms for downloading and executing applications as described in French Standard 

NF EN 726-3, the title of which translates as "Integrated circuit cards and terminals for 
telecommunications. Part 3: Specifications of the card independent of the applications". 

Depending on the security rules to which they are subject, the application programs 
can also be divided between these various locations. 
25 Figure 4B is a functional diagram showing a first software architecture configuration of 

the module 1 from figure 4A in which all application programs A1, A2, .... An and security 
functions (condensate computations, symmetrical cryptographic algorithms such as DES or triple 
DES, asymmetric cryptographic algorithms as proposed by RSA) are implemented in the secure 
microprocessor 3. 

3 0 The applications denoted A1, A2, .... An hereinabove and in the remainder of the 

description comprise at least the filters F1, F2, Fn and thus in particular the software for 
translating requests from the application service provider(s) FAp forming part of the main 
application 54 (figure 8A). 
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The standard microcontroller 2 manages the environment using various interface 

drivers: 

- a driver 21 for the microcircuit card reader or interface 6; 

- a driver 22 for the serial link interface 7; 
5 - a driver 23 for the keyboard 5; . 

- a driver 24 for the infrared link interface 8; 

- a driver 25 for the display 4; 

- a driver 26 for the clock 1 0 and the power supply 11; 

- a driver 27 for the DTMF interface 9; and 

io -a driver 28 for other interfaces, assuming that the module 1 includes one or more 

interfaces other than those represented in figure 2. 

The secure microprocessor 3 can therefore control the interfaces by means of 
commands which are interpreted by the interpreter 20 and executed by the standard 
microcontroller 2 using the drivers 21 -28. 

15 Figure 4C shows a second software configuration of the module 1 from figure 4A in 

which one or more applications Ax and one or more cryptographic functions Sx are stored in a 
reprogrammable memory 30a of a secure microprocessor 30 of a microprocessor card 31. 
When the card 31 is inserted into the reader 6, the microprocessor 30 executes the applications 
Ax and the cryptographic functions Sx. Other applications and security functions can be resident 

20 in and executed by the secure microprocessor 3 of the module 1. For example, the 
microprocessor 30 of the card 31 can assure an electronic signature function assuming that the 
secure microprocessor 3 does not include a dedicated computation processor (cryptoprocessor). 
Reciprocally, if the secure microprocessor 3 includes a cryptoprocessor, it is possible for an 
application on the microcircuit card 31 to invoke cryptographic commands of the module 1 that 

2 5 will be executed by the secure microprocessor 3. 

In this second configuration, which otherwise is identical to that of figure 4B, the 
interpreter 20 has the same role relative to the microprocessor 30 as it has relative to the secure 
microprocessor 3. Thus the module 1 can execute different applications according to the type of 
microcircuit card 31 inserted into the reader 6, for example: 

3 o - authentication of the user in the context of a banking transaction (balance enquiry, 

transfer of funds, etc) effected via a telephone line by means of the DTMF interface 9; 

- electronic purse balance enquiry or reloading from the module 1 when a microcircuit 
card 31 used as a purse is inserted into the reader 6. The module 1 offers the facility to manage 
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several different purses: bank purse, purse specific to an institution, for example; 

- reading a medical dossier on a medical card; 

- reading loyalty points on a card on which loyalty points are awarded to a consumer 
according to purchases made, participation in customer loyalty operation, etc. 

5 The mode of execution described hereinabove with reference to figure 4A and the 

software configurations shown in figures 4B and 4C likewise apply to a terminal based on a 
conventional PC additionally equipped with a secure microprocessor 3. In this mode of 
execution the microcontroller 2 corresponds to the PC 102 as shown in figure 2A, the processor 
unit 2a corresponds to the microprocessor 102c of the PC and the RAM 2b and the permanent 

10 memory 2c respectively correspond to the RAM 102d and the hard disk 102b. Likewise the 
inputs/outputs 102a of the PC correspond to the interface modules 7, 8 and 12 of figure 4A. The 
connection between the secure microprocessor 3 and the PC 102 can be a serial or parallel link 
or a connection to the PCMCIA type internal bus of the PC f or a direct connection to the PC 
motherboard. As an alternative to this, the secure microprocessor 3 can be fixedly or removably 

1 5 (via the connector 41 ) integrated with the PC keyboard. 

In this case the interpreter software module 20 and the peripheral driver software 
modules 21 through 28 are installed on and executed on the PC. The functional architecture of 
this mode of execution is equivalent to that shown in figure 2B, the interpreter module 20 
installed on the PC assuring the same role as the interpreter module. I from figure 2B: it executes 

20 . commands for controlling exchanges with the user received from the filter software F which is 
installed in a secure manner in the microprocessor 3 (Figure 4B) or the integrated circuit card 30 
(Figure 4C). 

The figure 5 diagram illustrates a second mode of execution of a second embodiment 
of the invention in which the electronic circuits of the terminal module 1 are based on a single 

2 5 microcontroller 29 replacing the microcontroller 2 and the microprocessor 3 and offering the 

same type of physical and logical protection as the microprocessors designed for integrated 
circuit cards. This microcontroller drives all the interface means 4-9 of the terminal module. It 
includes a processor unit 29a, a temporary memory (RAM) 29b, a permanent memory (ROM) 
29c and a semi-permanent memory (EEPROM) 29d for storing the translation software. The 

3 o processor unit 29a corresponds to both the data processing unit 2a controlling the interfaces and 

the processor unit 3a for executing the translation software. As previously, the terminal module 
1 can be based on a PC 102 to the internal bus of which is connected a secure microcontroller 
29 controlling the display screen 4 and the keyboard 5 of the PC directly. • 
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In one variant the memory in which the software for translating high-level requests is 
stored, volatile RAM with backup power supply or semi-permanent memory (EEPROM or Flash 
RAM), can be external to the microcontroller 29. In this case the translation software can be 
encrypted and signed or protected by a message authentication code (MAC) to assure its 
5 integrity and it confidentiality. The software is read by the microcontroller 29, decrypted and then 
executed. 

In a third mode of execution represented in figure 6 of the second embodiment of the 
invention the terminal module 101 has no secure microprocessor 3. In figure 6 the same 
reference numbers as in figure 4A denote the same elements. The microcontroller 2 controls the 

10 interface 6 and the switch-adapter 15 for connecting the secure microprocessor 130 of a 
programmable microcircuit card 131 in the interface 6 with the external link interface 7. In this 
case all of the applications A and the cryptographic functions C are stored in a semi-permanent 
memory (EEPROM or Flash RAM) 130a of the secure microprocessor 130 of the programmable 
microcircuit card 131 and implemented by the latter as described with reference to figure 4C in 

1 5 respect of the applications Ax and the cryptographic functions Cx. 

In the examples described previously, for simplicity, the microprocessor 30, 130 of the 
integrated circuit card and the secure microprocessor 3 possibly incorporated in the terminal 
module have a single communication port. This implies that in these examples exchanges 
between the various entities, i.e. the electronic unit 154 (figure 8) containing the main 

2 o application, the.secure microprocessor 3 and the microprocessor 30, 130 of the integrated circuit 
card, are effected via the microcontroller 2 or 29 of the terminal module. The above descriptions 
must not be considered as limiting on the invention: other implementations are feasible within the 
scope of the present invention. The secure microprocessors for integrated circuit cards currently 
available which can be used for the card itself (microprocessor 30, 130) or in the terminal module 

2 5 (microprocessor 3) can have two communication ports. Various embodiments optimising 

communication are therefore easy to envisage with this type of microprocessor. In figure 4C, for 
example, one port of the integrated circuit card 31 can. be dedicated to controlling the user 
interface and therefore connected to the microcontroller 2, the other port being connected to the 
electronic unit including the main application, subject to appropriate interface adaptation. 

3 0 According to one important feature of the invention filter software is stored in the 

reprogrammable memory EEPROM associated with the secure microprocessor 3 or 29 of the 
terminal module 1 and/or the secure microprocessor 30, 130 of the card 31, 131. This filter 
softwares translates in a manner known in itself high-level requests from the server Sap or from 
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the PC into sequences of elementary commands that can be executed by these microprocessors 
(these commands are defined in part 4 of ISO standard 7816-4). In accordance with the 
invention, this filter software translates these high-level requests into sequences of exchanges of 
data between the terminal module 1, 101 and the user via the interface means such as the 
5 display 4 and the keyboard 5. 

This solution has the advantage of considerably reducing the flow of data exchanged 
between the terminal module 1, 101 and the server Sap or the PC, but requires secure 
installation of the translation software to prevent instructions sent to the microcircuit card from 
being modified. 

io This filter software is an integral part of the portion of the application software installed 

in the terminal module 1 and/or the card 31, 131 and can therefore be downloaded. 

Figure 7 illustrates the conventional software architecture of a microcircuit card (smart 

card). 

The various software layers are represented by a block 43 which comprises a 
15 "communication protocol" software layer 44 enabling commands to be received. These 
commands are decoded by an "APDU command interpreter" software layer 45 (APDU: 
Application Protocol Data Unit) the role of which is to route the commands to the processing 
modules, which can be: 

- secure file management services software 46; 
20 - cryptographic services software 47; 

- application software 48. 

The processing modules 46, 47, 48 rely on basic services offered by the operating 
system 49 of the microcircuit card. 

Figure 8A illustrates the software architecture of a system for carrying out secure 

2 5 transactions using terminal modules 1 provided with a secure microprocessor 3 in accordance 

with the mode of execution of the invention shown in figure 4A. 

Block 51 represents the software executed by the secure microprocessor 3 of the 
terminal module 1, block 52 the software executed by the microcontroller 2 or the PC 102 of the 
terminal module 1 , block 53 the software executed by the microprocessor 30 of a microcircuit 

3 o card 31 and block 54 the main application software (application service provider) installed on the 

server Sap or on a PC. 

Block 51 is similar to block 43 of figure 7, i.e. the secure microprocessor 3 has an 
architecture similar to that of an integrated circuit card. Block 51 comprises: 



26 



- communication protocol software 60; 
-operating system 61; 

- a block 62 representing the portion of the application software installed in the terminal 
module 1, this portion of the application software essentially comprising the filter software 

5 previously mentioned. Various software modules of this type corresponding to various 
applications can co-exist in the secure microprocessor 3; 

- optionally, software 63 for authentication of the standard microcontroller 2 (by the 
secure microprocessor 3) and authentication of the secure microprocessor 3 of the terminal 
module 1 (by the microprocessor 30 of the card 31 ); 

1 o - secure file management software 64; 

- cryptographic services software 65. 
Block 52 comprises: 

- communication protocol software 70; 

- a command interpreter 71 corresponding to the software 20 from figures 4B and 4C; 
15 - authentication software 72 for authentication of the standard microcontroller 2 (by the 

secure microprocessor 3 of the terminal module 1) in conjunction with the software 63; 

- software 73 for controlling resources internal to the microcontroller 2; 

- software 74 for controlling interfaces with the user drivers 23 and 25 for the screen 4 
and the keyboard 5); 

20 -software 75 for controlling the communication interfaces 7, 8 and 9 (drivers 22, 24, 

27). 

Finally, block 53 is similar to block 43 but in the example described with reference to 
figure 8A does not include any application or filter software. It comprises: 

- communication protocol software 80; 

2 5 - APDU command interpretation software 81 ; 

- secure file management services (for example PIN checking) software 82; 
-cryptographic services software 83 (symmetrical cryptographic computations using 

secret keys or asymmetric cryptographic computations using public and private keys, etc) for 
authentication of the secure microprocessor 3 of the terminal 1 (by the microprocessor 30 of the 

3 o card 31) in conjunction with the software 63, among other functions; 

- the operating system 84 of the microprocessor 30 on the card 31 . 

The communication protocol 60, 70, 80 controls exchange of data between: 

-the microprocessor 30 of the card 31 and the standard microcontroller 2 of the 
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PC 1 02 of the terminal module 1 ; 

- the secure microprocessor 3 and the microcontroller 2 of the terminal module 1 ; 

- the secure microprocessor 3 of the terminal module 1 and the microprocessor 30 of 
the card 31. 

5 Figure 8B is a view similar to figure 8A illustrating the software architecture of the 

system in the situation where the terminal module 101 does not include the secure 
microprocessor 3, in accordance with the third mode of execution of the second embodiment of 
the invention (figure 6). 

In figure 8B, block 152 represents the software executed by the microcontroller 2 of the 

10 terminal module 101, block 153 the software executed by the microprocessor 130 of a 
programmable microcircuit card 131, and block 154 the main application software installed on 
the server Sap or on a PC. 

Block 152 comprises the same software 70, 71 and 73 through 75 as block 52 from 
figure 8A and a block 76 which comprises software for authentication of the standard 

15 microcontroller 2 of the terminal module 101 (by the microprocessor 130 on the card 131). 

Block 153 relating to the microprocessor 130 of the card 131 comprises software 62 
and 80 through 84 of blocks 51 and 53 from figure 8A together with software 77 for 
authentication of the standard microcontroller 2 of the terminal module 101 (by the 
microprocessor 1 30 of the card 1 31 ) in conjunction with the software 76. 

2 o Unlike a conventional system, in a secured transaction system of the invention the filter 

software 62 which translates high-level requests from the application into elementary commands 
that can be executed by a microcircuit card is installed in the secure user environment, i.e. either 
in the terminal module 1 (for the applications A1, A2, .... An of the modes of execution from 
figures 4A-4C and 5) or on a semi-permanent memory card 31, 131 which can be used with the 

2 5 terminal module 1, 101 (for the applications Ax of the figure 4C embodiment and for all the 

applications of the figure 6 embodiment). 

Apart from its microcircuit card management function, the filter software 62 controls 
interaction with the user, i.e. the sequences of exchanges of data between a user and the 
terminal module which are required in the context of an application and which use the interface 

3 0 means, namely the screen 4 and the keyboard 5. Note that the invention is not limited to the use 

of a screen and a keyboard as interfaces with the user and that any other type of interface with 
the required ergonomic features could be suitable, for example a voice interface. 

Transactions are secure because the filter software 62 is securely installed in the 
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secure microprocessor 3 or 29 of the terminal module 1 or the microprocessor 30, 130 of the 
microcircuit card 31, 131. The keys and rules necessary to access files on the microcircuit card 
31, 131 are contained in the translation software 62 and are therefore inaccessible to third 
parties. 

The functions of the filter software 62 will be illustrated hereinafter in the context of an 
example of an electronic trading application. The application includes the following entities: 

• a purchaser, 

• a merchant, 

• a bank. 

The merchant has an electronic trading server Sap (Web server) accessible via the 
Internet. The purchaser has: 

•a PC for accessing the electronic server Sap to consult a catalogue of products, 

•an integrated circuit card 31 supplied by the bank and the microprocessor 30 in which contains 

a private key but does not have any cryptographic capabilities connected with a signature, 
•a terminal module 1 as shown in the figure 4A embodiment, having a standard microcontroller 

2, a secure microprocessor 3 with cryptographic capabilities enabling a message to be 

signed, a keyboard 5, a display 4, an integrated circuit card interface 6 and a serial interface 

7 for connecting it to a PC. 

The principle of operation is as follows: the transaction is signed by the terminal 
module 1 using a private key held by the card 31 . This private key is protected by a confidential 
code (PIN) that the purchaser must enter in a secure environment, i.e. on the terminal 1 , and by 
prior authentication of the terminal 1 by the card 31 using a secret key Kauth. The private key is 
also transmitted in an encrypted manner (by means of a key Kchif) to set-up a secure 
communication channel between the microprocessor 30 of the integrated circuit card 31 and the 
secure microprocessor 3 of the terminal 1 . 

Figure 9 illustrates the exchanges between the various entities: 

a. the purchaser enters an order on the PC, 

b. the PC generates the transaction to be signed by the purchaser (product code, price) and 
requests the terminal module 1 to sign the transaction, 

c. the terminal module verifies the source of the request for signature and then prompts the user 
to enter their PIN code by displaying a message "enter PIN" on the display 4, 

d. the purchaser enters the code (PIN) on the keyboard 5 of the terminal module 1, 



e. the terminal module 1 sends the PIN to the card 31 for verification; positive verification lifts 
one of two conditions of access to reading the private key, 

f. the terminal module 1 displays the transaction on its display 4, 

g. the purchaser confirms it by pressing a "confirm" key on the keyboard 5 of the terminal module 
1, - 

h. the terminal module 1 submits an external authentication request to the card 31. External 
authentication enables the secure microprocessor 3 of the terminal module 1 to authenticate 
itself to the microprocessor 30 of the card 31 and thereby lift the second level of protection of 
access to the private key. This authentication is performed in challenge/response mode using a 
secret Kauth shared by the terminal module 1 and the card 31, 

L the terminal module 1 sends a private key read request to the card 31 , 
j. all access conditions having been satisfied, the card 31 accepts the read request and sends 
the private key, which is encrypted using a secret key Kchif shared by the card 31 and the 
terminal module 1, 

k. the terminal module 1 decrypts the private key, signs the transaction by means of the private 
key, destroys the private key, disconnects from the card 31 and sends the signed transaction to 
the PC which sends it to the server S. 

The above example can easily be transposed to an electronic transaction performed 
without any PC, the terminal module 1 being connected directly to a server Sap by a modem link 
(figure 3), the purchaser entering the order (product code) on the terminal module 1. 

Note that authentication of the secure microprocessor 3 by the card can also be 
effected by way of the read private key command by associating with it a message 
authentication code (MAC) calculated using a secret key. 

This example shows that the filter software 62 can translate a high-level "request for 
transaction signature" into a multitude of individual requests addressed to the various interfaces 
of the terminal interface 1, namely its interface 6 with the integrated circuit card 31, its interface 
with the display 4, its interface with the keyboard 5 and its interface for connecting it to the PC or 
the server Sap. 

Translation filter software of this kind has a screening role, providing a filter between 
the outside world, i.e. the applications, and the peripheral devices that it controls. 
It enhances security because: 

1. It imposes a sequencing of the individual instructions sent. For example, in the 
situation illustrated hereinabove, it requires the transaction to be confirmed by the user before it 
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is signed. 

2. It alone has the secret parameters for generating and authenticating these individual 
instructions. Thus it alone has the authentication and encryption keys for reading and decrypting 
the private key. 

5 When the filter software executes in the secure microprocessor 3 of the terminal 

module 1 these properties enable a policy of access to the card 31 to be imposed which is not 
always completely imposed by the card itself, or the capacities of a card to be expanded 
(signature capacity delegated to the terminal module, use in a context not foreseen when initially 
deployed). 

io The advantages in terms of security of executing the filter software in the secure 

microprocessor of the terminal module or the integrated circuit card are possible only because 
the software executes in a secure environment, assuring that: 

• the secrets contained in the filter software are not accessible because they are stored in the 
secure microprocessor 3 f 29, 30 or 130, 
15 • the confidentiality and the integrity of the filter software are preserved because the software 
is stored in the secure microprocessor 3, 29, 30 or 130. 

If the terminal module 1 is a dedicated product having its own interfaces (display 4 and 
keyboard 5) the security objective is achieved because the software controlling exchanges of 
data with the user cannot be modified because it is permanently stored in the permanent 
2 o memory 2c of the microcontroller 2 or securely stored in the microcontroller 29. Thus the user 
can confidently confirm the content of their transaction by means of the display 4 and the 
keyboard 5 and the need to verify the identity of the application or the source and the integrity of 
requests becomes optional. 

Other mechanisms can further enhance the level of security of the chain of confidence 

2 5 between the secure microprocessor of the integrated circuit card, the secure microprocessor of 

the terminal module, when present, the standard microcontroller or the PC of the terminal 
module and the user. These mechanisms are: 

A) secure downloading of the filter software; 

B) authentication of the standard microcontroller by the secure microprocessor or 

3 o (which amounts to the same thing but is more suitable in the case of a mode of execution of the 

terminal based on a PC) authentication of the interpreter software module I (20) by the filter 
software F (62) and/or setting up of a secure communication channel between these two 
microprocessors or the programs I and F; 
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C) protection of a secret by the standard microcontroller; 

D) mutual authentication and setting up of a secure communication channel between 
the secure microprocessor of the integrated circuit card and the secure microprocessor of the 
terminal module; 

5 E) authentication of the terminal module and where applicable of the terminal 

module/card combination; and 

F) authentication of the microcircuit card by the terminal module. 
A) Secure downloading of the filter software 

The figure 10 flowchart illustrates the process of downloading an application program 
10 (filter software) into the secure microprocessor 3 or 29 of the module 1 or the secure 
microprocessor 30, 130 of a card 31, 131 in the reader 6. This downloading can be effected 
from a server Sap via the PC and the external connection interface 7 or the infrared link interface 
8, for example, or directly by means of a telephone connection via the DTMF interface 9. The 
downloading can equally be effected into the secure microprocessor 3 or 29 (if the terminal 
1 5 module has one) from a microcircuit card inserted into the reader 6. 

In step 32 the area of the memory 3d allocated to the application program to be 
received is empty and the microprocessor 3 is waiting to load the application program following a 
loading request. 

The next step 33 corresponds to a procedure for authentication by the microprocessor 
20 3 of the entity that will download the application program (sender). This authentication 
procedure can use encryption mechanisms well known to the skilled person, for example, such 
as symmetrical mechanisms using shared secret keys or asymmetrical mechanisms using 
private and public keys. 

Step 34 is a test to determine if the authentication procedure has succeeded. If it has 

2 5 not, the message "access refused" is displayed on the screen 4 (step 42) and the program 

returns to step 32; if authentication has succeeded, the process for loading the application 
program begins in step 35. 

Step 36 corresponds to storage in the EEPROM 3d of the data frames sent by the 
entity responsible for downloading. 

3 0 Step 37 is a test to determine if downloading has finished: if not, the downloading 

program returns to step 36 and downloading continues; if it has finished, the microprocessor 3 
verifies the integrity of the received data in step 38. To this end a message authentication code 
(MAC) can be associated with the downloaded program for verifying not only its integrity but also 
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its source. The MAC can be generated using a symmetrical cryptography mechanism (DES in 
chained CBC mode). The source and integrity can also be verified using an asymmetrical 
cryptography mechanism: a condensate of the downloaded software is signed by the sender 
using their private key; the secure microprocessor 3 then verifies the signature using the 
5 sender's public key. 

Note that in this last example the public key in theory does not need to remain 
confidential. The security features of the microprocessor nevertheless assure the integrity of the 
software, preventing a hacker from modifying the software to eliminate the signature verification 
or simply to substitute for the public key initially provided a public key for which they know the 
10 associated private key. 

If the test 39 indicates that the data received is correct, a flag indicating that the 
application program received is valid is generated in step 40. Otherwise the downloading 
program returns to the first step 32. 

This process of loading the application software, and thus the filter software, into the 
15 secure reprogrammable memory (3d, 30a, 130a depending on the embodiment concerned) 
includes mechanisms for confirming the source and the integrity of the data received from the 
sender of the software. This prevents downloading by a hacker of filter software that could carry 
out transactions in the terminal module 1, 101 unknown to the user. 

B) Authentication of the interpreter software module I, 20, 71 by 
20 the filter software F, 62 or, which amounts to the same thing in the 
corresponding mode of execution, authentication of the standard 
microcontroller 2 by the secure microprocessor and/or setting up of a 
secure communication channel between the programs or between the 
microprocessors 

2 5 For a user to be totally confident in the terminal module they are using to carry out 

transactions it is necessary: 

-to authenticate the data sent from the interpreter software 20, 71 to the secure 
microprocessor 3, 30 or 130 executing the filter software; and 

-to assure that the data sent by the filter software to be displayed through the 

3 0 intermediary of the user's interpreter software of the terminal module 1, 101 can only be 

displayed by the latter. 

When the means of controlling exchange of data with the user, i.e. the interpreter 
software 20, 71, is installed in the terminal module 1, 101 in a fixed manner and cannot be 



modified, for example in the ROM 2c of the standard microcontroller 2, authenticating the 
software module is equivalent to authenticating the microcontroller. 

Likewise, when the filter software is installed in secure processing means such as the 
secure microprocessors, the integrated circuit card or the secure server Ssec, in a manner such 
that it cannot be modified by an unauthorised person, authentication by these secure means is 
equivalent to authentication by the filter software itself. 

In the following description the mechanisms for authentication of the software means 
controlling the interfaces or the interpreter software 20, 71 by the filter software will be described. 

Various solutions verify these conditions. 

A first solution consists in encrypting all the data exchanged between the interpreter 
software 20, 71 and the filter software. 

A second solution is to have the interpreter software 20, 71 authenticated by the filter 
software and/or to set-up a secure communication channel between them. 

These two solutions necessarily imply that at least one secret parameter known to the 
filter software F 62 is stored in the interpreter software 20, 71 . - 

In the second solution the filter software F 62 authenticates the interpreter software 20, 
71 using a conventional authentication process based on information sent by the interpreter 
software 20, 71 and combined with the secret parameter. At the level of the interpreter software 
20, 71 this authentication procedure is executed by the software 72 (figure 8A) or the software 
76 (figure 8B), depending on the embodiment of the terminal module concerned. 

This authentication mechanism can equally be applied to messages exchanged 
between the programs to construct message authentication codes for guaranteeing the source 
and the integrity of each message transmitted. 

In the case of the mode of execution described with reference to figure 4A, this solution 
nevertheless requires, for preference, physical protection of the link between the two 
microprocessors to be assured to prevent a hacker from reading the data exchanged and in 
particular the personal identification code (PIN) of the card, which the user may need to enter via 
the keyboard 5 to carry out transactions. 

C) Protection of a secret parameter by the standard 
microcontroller 2 

The foregoing description shows the necessity of storing at least one secret parameter 
in the interpreter software. The mode of execution of the terminal based on a PC, in which the 
interpreter software executes on the PC itself, therefore offers a limited degree of security for the 



PC, although this degree of security is sufficient to prevent a virus substituting itself for the 
interpreter software. A higher degree of security is obtained by installing the interpreter software 
in the ROM 2c of the standard microcontroller 2. For enhanced security the secret parameter of 
the microcontroller 2 can be stored in the temporary memory when the product is manufactured 
or possibly on inserting the microprocessor 3 if it is removable, or on an integrated circuit card. 
The aim of this operation is to establish confidence between the two microprocessors. All 
necessary precautions must be taken at the time of this operation to assure the authenticity of 
the microcontroller 2 (operation effected by the manufacturer, operation protected by transport 
keys stored in the temporary memory of the microcontroller 2 by the manufacturer, and 
knowledge of which is a precondition for initialising said secret parameter). In addition, 
conventional mechanisms for detecting intrusion (contacts, etc) will be fitted to erase the 
temporary memory in the event of intrusion (by cutting off the power supply, etc). 

D) Mutual authentication and setting up of a secure 
communication channel between the microprocessor of the integrated 
circuit card and the secure microprocessor of the terminal module 

This mutual authentication and the setting up of the secure communication channel are 
effected by mechanisms identical to those used by the standard microcontroller 2 and the secure 
microprocessor executing the filter software, as described under B) above. 

E) Authentication of the terminal module 

It is important to guard against any attack on the combination of the keyboard 5, 
display 4 and secure microprocessor 3 with the aim of counterfeiting the terminal module, for 
example, substituting a counterfeit terminal module for a real terminal module in order to recover 
information entered by the user (keyboard spy), access the secrets of an integrated circuit card, 
falsify signatures. 

To this end a mechanism can be added to enable the user to authenticate the terminal. 

This objective is achieved by an automatic personalisation process. 
Authentication of the terminal module alone 

Personalisation can consist in calculating a password that is easy to remember and 
that is generated and displayed by the terminal in accordance with secret parameters contained 
in the microprocessor or microprocessors of the terminal when the user enters a PIN. If the 
terminal includes two microprocessors, for example, the password is stored in the secure 
microprocessor, encrypted using the PIN and a secret key X, and then sent to the microcontroller 
2 where it is decrypted using the key X also stored in the microcontroller 2 and the PIN entered 
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by the user. This mechanism aims to protect against substitution of one of the two 
microprocessors. 

The same principle can be applied to a card/terminal combination each time a 
microcircuit card is used with the terminal module. Personalisation can consist in the translation 
5 software calculating a password based on secret information held by the secure microprocessor 
of the card and secret information held by the terminal module, for example. The same principle 
as described hereinabove can be used to calculate the password. This password, generated the 
first time the terminal module js used in conjunction with the card and known to the user, is 
displayed on the screen 4 when the terminal module is used again with the card, The user can 
10 therefore verify and be assured that the terminal in their possession, consisting of the terminal 
module connected to the card, is authentic. 

F) Authentication of the microcircuit card by the terminal module 
To enhance further the security of the transaction system in accordance with the 
invention, a conventional authentication process can be used for authentication by the terminal 
15 module 1, 101 of the microcircuit card used. An authentication process of the above kind 
prevents the user's personal identification number (PIN), entered by the latter into the module 1, 
101 via the keyboard 5 to execute a secured transaction, from being captured by a counterfeit 
card substituted by a hacker for the user's authentic card and subsequently recovered by the 
hacker to read the PIN off the counterfeit card. This authentication can be effected by a means 
2 0 of a conventional challenge/response type mechanism, for example, using a secret shared 
between the card and the terminal module and symmetrical cryptography or, as already 
described, using a private key stored by the card enabling the challenge to be encrypted using 
an asymmetrical algorithm, the terminal module verifying the response using its public key. 

The architecture of the transaction system and the security mechanisms described 
25 hereinabove make transactions effected by means of the terminal module 1 , 101 highly secure. 
The terminal module: 

- expands the nature of the truly secure services that a microcircuit card can provide, 
thanks to the keyboard 5, the screen 4 and the protection of data exchanged with the user; and . 

- enables the card to be used in a non-secure environment (PC susceptible to viruses 
30 or pirate programs), by hermetically isolating it from this environment by means of a software 

and/or hardware architecture strictly controlling access to the card, i.e. controlling commands 
sent to the cryptographic functions on the card. 

The terminal module can take various forms, for example: 
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•an integrated circuit card reader for connection to a computer via various interfaces (PCMCIA, 

etc) or not (connection to a server via modem only); 
•a computer (PC) the user interfaces of which consist in the screen and the keyboard of the PC 
and which includes an integrated circuit card reader. The PC will include software and/or 
5 hardware means (such as a secure second microprocessor, the standard microprocessor 

consisting of the PC itself) for assuring the integrity and the confidentiality of the filter 
software. By computer is meant a PC or a PDA (Personal Digital Assistant); 
•a keyboard, possible provided with an LCD display screen, incorporating a secure 
microprocessor and an integrated circuit card interface; 
10 •a telephone, possible equipped with a display, incorporating a secure microprocessor and an 
integrated circuit card interface; 
•a cable TV network decoder (set-top box) incorporating an integrated circuit card reader 
connected to a TV, the telephone, a keyboard or possibly the remote controller for the 
decoder or the TV providing the user interface; 
15 ©more generally, any equipment that can be rendered secure by incorporating a secure 
microprocessor in which a sensitive application can be installed or by incorporating an 
integrated circuit card interface enabling said equipment to be controlled by an application 
installed on an integrated circuit card. 

The whole of the foregoing description describes a terminal to be used with an 
20 integrated circuit card or smart card. The card referred to is in fact a tool enabling the use of 
cryptographic functions personalised to one user by means of at least one secret parameter. 
The object of the invention is clearly not limited to a given form of tool such as an integrated 
circuit card. The invention also covers the use of personal security devices offering functions 
equivalent to those of an integrated circuit card but presented in a different form, such as the 
2 5 "iButton", "Java Ring" and "token" products. 



CLAIMS 

1. A terminal for execution of secure electronic transactions by a user in conjunction 
with at least one application installed on an electronic unit, said terminal comprising: 

- a terminal module including at least: 

* first interface means with said application for receiving from it requests 
relating to said transactions, 

* second interface means with said user; 

* third interface means with a personal security device, 

* first data processing means comprising at least first software means for 
controlling said interface means, and 

- a personal security device including at least second secure data processing means 
comprising at least second software means for executing elementary commands and means for 
executing cryptographic computations, 

characterised in that: 

- said terminal (1, 31; 101, 131) is adapted to receive said requests from said 
application (Fap) installed on said electronic unit (Sap; PC) in the form of high-level requests 
independent of said personal security device, 

- at least one of said terminal module (1; 101) and said personal security device 
comprises : 

* at least one reprogrammable memory (3d; 30a; 102b; 130a; Ssec)for storing 
at least one filter program (F, 62) translating said high-level requests into at least one of 
either: 

(i) at least an elementary command or a sequence of elementary commands that can 
be executed by said second software means (80-84) of said second data processing means (30; 
130), or 

(ii) at least one sequence of data exchanges between said terminal module (1 ; 101) 
and said user via said second interface means (4, 5), which can be executed by said first 
software means (1, 20, 71) of said first data processing means (2; 29; 102), and 

* means for protecting said filter program (F, 62) to prevent an unauthorised 
entity from either reading and/or modifying said filter program, and 

- at least one of said first and said second data processing means (3; 29, 30; 102; 130; 
Ssec) comprise a data processing device for executing said filter program (F, 62). 

2. A terminal according to claim 1 characterised in that said device for executing the 
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filter program comprises first means for identifying and/or authenticating said application (Fap) 
installed on said electronic unit (Sap; PC) or the source of said requests sent by said application. 

3. A terminal according to claim 2 characterised in that said data processing device for 
executing said filter program (F, 62) comprises means for verifying the integrity of data received 
from said application (Fap). 

4. A terminal according to any one of claims 1 to 3 characterised in that said data 
processing device for executing said filter program (F, 62) comprises centralised means (Ssec) 
for controlling conditions of Use of services of the personal security device (31) in accordance 
with said application (Fap) and/or the user. 

5. A terminal according to any one of claims 1 to 4 characterised in that said data 
processing device for executing said filter program (F, 62) comprises: 

- means for commanding loading in a secured manner of said filter program into said 
programmable memory via said first or said third interface means from an entity external to said 
module, and 

- first access control means for authorising said loading of said filter program only in 
response to at least one predefined condition. 

6. A terminal according to any one of claim 1 to 5 characterised in that it comprises 
second means for authenticating said first data processing means (2; 3; 29; Ssec) by said 
second data processing means (30; 130). 

7. A terminal according to any one of claims 1 to 6 characterised in that it comprises 
third means for authenticating said second data processing means (30; 130) by said first data 
processing means (3; 29). 

8. A terminal according to claim 6 or claim 7 characterised in that it comprises a first 
communication channel (6) between said first data processing means (2; 3; 29) and said second 
data processing means (30; 130) and first means for securing said first communication channel. 

9. A terminal according to any one of claims 1 to 8 characterised in that it comprises 
fourth means for authentication of said terminal module (1; 101) by said user, independently of 
said personal security device (31; 131). 

10. A terminal according to claim 9 characterised in that said fourth authentication 
means comprise means for calculating by said first data processing means (2; 3; 29) and for 
presentating to said user via said second interface means (4) a password known to said user 
and calculated on the basis of a first secret parameter stored in said first data processing means 
(2; 3; 29). 



39 



1 1 . A terminal according to any one of claims 1 to 10 characterised in that it comprises 
fifth means for conjoint authentication of said terminal module (1 ; 101) and said personal security 
device (31 ; 131) by said user. 

12. A terminal according to claim 11 characterised in that said fifth authentication 
5 means comprise means for calculating by said device for executing said filter program (3; 29; 31 ; 

131) and for presentating to said user via said second interface means (4) a password known to 
said user and calculated on the basis of at least second and third secret parameters stored 
respectively in memory in said first data processing means (2; 3; 29) and in memory in said 
: second data processing means (30; 130). 
io 13. A terminal according to any one of claims 1 to 12 characterised in that said 

terminal module (1) includes said programmable memory (3d) for loading and storing said filter 
program (F, 62). 

14. A terminal according to claim 13 characterised in that said filter program (F ( 62) 
generates first commands for implementing said at least one sequence of exchanges of data 

15 between said terminal module (1) and said user and said first data processing means comprise a ^ 
first microprocessor (2; 102) for controlling said interface means (4-9) programmed by virtue of 
said first software means (20; 71) for controlling said interface means to execute said first 
commands generated by said filter program (F, 62), and a second secure microprocessor (3) of 
the integrated circuit card type disposed in said terminal module and including said 

2 o programmable memory (3d), said second microprocessor (3) executing said filter program (F f 62) 
to control said at least one sequence of exchanges of data by means of said first commands 
sent to said first microprocessor (2) and for applying said at least one elementary command or 
sequence of elementary commands to said second data processing means. 

15. A terminal according to claim 14 characterised in that said first software means 

2 5 (20, 71) for controlling the interface means include at least a fourth secret parameter, said 

second microprocessor (3) being controlled by said filter program (F, 62) to authenticate said first 
software means (20 t 71) for controlling the interface means on the basis of information sent by 
said first microprocessor (2) and combined at least with said fourth secret parameter. 

16. A terminal according to claim 15 characterised in that it comprises a second 

3 0 communication channel (12) between said first software means (20, 71) for controlling the 

interface means and said second microprocessor '(3) and second means for securing said 
second communication channel. 

17. A terminal according to claim 16 characterised in that said second securing means 
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comprise means for encryption and decryption by said first software means (20, 71) and by said 
second microprocessor (3), of data sent on said second communication channel (12) on the 
basis of at least a fifth secret parameter stored in memory in said first and second data 
processing means. 

5 , 18. A terminal according to claim 16 or claim 17 characterised in that said second 

securing means comprise first physical means for protecting said second communication 
channel (12) against intrusion. 

19. A terminal according to any one of claims 15 to 18 characterised in that said first 
microprocessor (2) includes a temporary memory (2b) for storing said secret parameter and 

10 second means for physically protecting said temporary memory (2b) against intrusion. 

20. A terminal according to any one of claims 14 to 19 characterised in that said 
second microprocessor (2) is a microcontroller. 

21 . A terminal according to claim 13 characterised in that said filter program generates 
first commands for implementing said at least one sequence of data exchanges between said 

15 terminal module and said user and said first data processing means comprise said device for 
executing said filter program and consist in a secure microprocessor (29) adapted to: 

* execute said filter program (F, 62) for translating and converting said high-level 
requests into at least one sequence of data exchanges between the terminal module and the 
user and/or into at least one elementary command or a sequence of elementary commands that 

2 o can be executed by said second software means of said second data processing means (31), 

* control said interface means (4-9) using said first commands generated by said filter 
program to implement said at least one sequence of exchanges between said terminal module 
(1) and said user. 

22. A terminal according to claim 21 characterised in that said microprocessor (29) 

2 5 includes said programmable memory. 

23. A terminal according to claim 21 characterised in that said programmable memory 
is external to said microprocessor (29). 

24. A terminal according to claim 23 characterised in that said filter program (F, 62) is 
stored in encrypted form in said programmable memory and in that said microprocessor (29) 

3 o comprises means for reading, decrypting and executing said filter program. 

25. A terminal according to any one of claims 14 to 24 characterised in that said 
second data processing means of said personal security device (31) comprise a second data 
processing device (30) for secure execution of a filter program and a programmable memory 
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(30a) for loading and storing said filter program (62), said first software means of said first data 
processing means being adapted to receive said commands for implementing said at least one 
sequence of exchange of data from either of said filter program executing devices (3; 29; 31) 
installed in said module and said personal security device, respectively. 
5 26. A terminal according to any one of claims 13 to 25 characterised in that: 

- said filter program (F, 62) comprises at least one secret parameter, 

- said second data processing means (30) comprise second means of conditional 
access control for authorising execution of said cryptographic computations in response to 
elementary commands generated by said filter program (F, 62) only if at least a second 

1 o predefined condition depending on said secret parameter is satisfied. 

27. A terminal according to any one of claims 1 to 12 characterised in that said 
personal security device (131) includes said programmable memory (130a) for loading and 
storing said filter program (F, 62). 

28. A terminal according to claim 27 characterised in that said filter program (F, 62) 
is generates first commands for implementing said at least one sequence of exchanges of data 

between said terminal module (1) and said user and said first data processing means comprise a 
first microprocessor (2; 102) for controlling said interface means (4-9), programmed by said first 
software means 
(20, 71), to execute said first commands generated by said filter program (F, 62), and said 
20 second data processing means comprise a secure second microprocessor (130) of the 
integrated circuit card type disposed in said personal security device (131) and including said 
programmable memory (130a), said second microprocessor (130) executing (i) said filter 
program (F, 62) for controlling said at least one sequence of exchanges of data by means of said 
first commands sent to said first microprocessor (2; 102), and (ii) said elementary commands. 

2 5 29. A terminal according to claim 6 and claim 28 characterised in that said first 

software means (20, 71) for controlling said interface means include at least one secret 
parameter and said second microprocessor (130) of said personal security device (131) is 
controlled by said filter software (62) to authenticate said first microprocessor (2) on the basis of 
information sent by said first microprocessor (2) and combined at least with said secret 

3 0 parameter. 

30. A terminal according to claim 28 or claim 29 characterised in that said second 
microprocessor (130) of said personal security device (131) is adapted to command the loading 
of said filter program (F, 62) into said programmable memory (130a) via said first interface 
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means (7-9) and said third interface means (6) with said personal security device (131). 

31. A terminal according to any one of claims 13 to 30 characterised in that said 
terminal module (1; 101) is an integrated circuit card reader and said personal security device is 
an integrated circuit card (31; 131). 
5 32. A terminal according to claim 13 characterised in that said terminal module (1) 

comprises a personal computer (102) and in that said reprogrammable memory is included in the 
hard disk (102b) of said computer. 

33. A terminal according to claim 32 and any one of claims 14 to 17 characterised in 
that said first microprocessor is the microprocessor (102c) of said personal computer (102), said 

10 personal computer (102) being also interfaced to said secure microprocessor (3). 

34. A terminal according to claim 32 characterised in that said filter program (F) 
comprises a loading/decryption first module (Fed) and an encrypted second module (Fchi) for 
said translation of high-level requests, said first module (Fed) commanding the loading of said 
second module (Fchi) into RAM of said computer (102) and its decryption for execution of said 

15 filter program by said computer. 

35. A terminal according to claim 32 characterised in that said filter program (F) 
comprises at least one first module (F-PC) installed on said personal computer (102) and at least 
one second module (F-SE) installed on a security server (Ssec), said personal computer (102) 
and said security server (Ssec) being connected by a secure communication channel (CS) 

2 o enabling protected exchange of data between said modules. 

36. A terminal according to any one of claims 32 to 35 characterised in that said 
personal security device (31) is an integrated circuit card. 

37. A system for performing secure transactions characterised in that it comprises at 
least one terminal (1, 31; 101, 131) according to any one of claims 1 to 36 and at least one 

2 5 electronic unit (Sap; PC) including means for transmitting said high-level requests to said 
terminal(1 f 31; 101, 131). 

38. A system according to claim 37 characterised in that it comprises a plurality of 
terminals (1 ( 31; 101, 131), at least one server (S) constituting said electronic unit and means 
(CR) for sending digital data between said server (S) and said terminals. 



TITLE : Terminal and system for performing secure electronic transactions. 



ABSTRACT OF THE DISCLOSURE 

The terminal includes a terminal module (1) and a person security device (31). The 
terminal module (1) is adapted to receive requests from an application (Fap) installed on an 
electronic unit in the form of high-level requests independent of the module (1) and of said 
personal security device (31). 

The terminal module (1) and/or the personal security device (31) includes a 
reprogrammable memory for storing and means for executing a filter program (F) translating the 
high-level requests into at least one of either (i) at least one sequence of exchanges of data 
between the terminal module (1) and the user or (ii) at least one elementary command or a 
sequence of elementary commands that can be executed by the personal security device, 
together with means for protecting said filter program (F, 62) to prevent any modification of said 
program by an unauthorised person. The filter program comprises means for identifying and/or 
authenticating the source of requests sent by said application (Fap) installed in said unit. 
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